NTN IoT Rel-17

 RAN1#103-e

8.15   Study on NB-IoT/eMTC support for Non-Terrestrial Network

Please refer to RP-193235 for detailed scope of the WI

R1-2009838        Session notes for 8.15 (Study on NB-IoT/eMTC support for Non-Terrestrial Network)            Ad-Hoc Chair (Ericsson)

R1-2007882         NB-IoT Waveform Tests over LEO Satellite OQ Technology

R1-2009096         Rel-17 IoT NTN Work Plan             MediaTek Inc., Eutelsat

8.15.1     Scenarios applicable to NB-IoT/eMTC

R1-2007572         Application scenarios of IoT in NTN             Huawei, HiSilicon

R1-2007844         Application scenarios discussion on NB-IoT/eMTC   CATT

R1-2008038         Discussion on scenarios for IoT NTN            CMCC

R1-2008199         On Scenarios applicable to NB-IoT/eMTC   Samsung

R1-2008257         Discussion on scenarios applicable to NB-IoT/eMTC OPPO

R1-2008815         Reference Link-Budget parameters for IoT NTN         Eutelsat S.A.

R1-2008854         Preliminary views on the scenarios and assumption for IoT-NTN           ZTE

R1-2009007         On scenarios for NB-IoT and eMTC NTN    Intel Corporation

R1-2009042         Discussion on the scenarios for NB-IoT/eMTC over NTN        Xiaomi

R1-2009088         On scenarios and evaluations for eMTC and NB-IoT based NTN            Ericsson

R1-2009098         Discussion on scenarios applicable to NB-IoT over NTN          Sateliot

R1-2009114         Scenarios applicable to NB-IoT/eMTC          Qualcomm Incorporated

R1-2009215         Observations on NB-IoT/eMTC for NTN scenarios    Nokia, Nokia Shanghai Bell

R1-2009235         Scenarios for support of NB-IoT and eMTC over NTN             Sony

R1-2009304         Discussion on IoT NTN scenarios - link budget          MediaTek Inc., Eutelsat

[103-e-NR-NB_IoT_eMTC_NTN] – Sanaa (Eutelsat)

Email discussion/approval on scenarios applicable to NB-IoT/eMTC for NTN with checkpoints for agreements on 11/5, 11/10, 11/12

R1-2008868        Email summary discussion in scenario applicable to NB-IoT/eMTC Moderator (Eutelsat)

Decision: As per email decision posted on Nov.13^th,

Agreement:

IoT NTN scenarios A, B, and C are included in the study as shown below:

Agreement:

The following IoT NTN reference scenario parameters are agreed:

NOTE 1:    Each satellite has the capability to steer beams towards fixed points on earth using beamforming techniques. This is applicable for a period of time corresponding to the visibility time of the satellite.

NOTE 2:    This beam size refers to the Nadir pointing of the satellite. 

NOTE 3:    The Maximum beam foot print size for GEO is based on current state of the art GEO High Throughput systems, assuming either spot beams at the edge of coverage (low elevation) or a single wide-beam.

NOTE 4:    The use of a Circular polarized antenna is optional.

NOTE 5:    Same Noise Figure of 7 dB as in Release 16 TR 38.821 or 9 dB as in Release 12 TR 36.888  for device can be assumed for link budget. The noise figure is device vendor implementation specific. 

NOTE 6:    Max Doppler shift and Max Doppler shift variation in the absence of any device pre-compensation of satellite Doppler shift on the service link.

NOTE 7:    System bandwidth is FFS

8.15.2     Necessary changes to support NB-IoT and eMTC over satellite

A placeholder only: contributions may be submitted but will not be formally handled

R1-2007573         Solutions to support IoT in NTN     Huawei, HiSilicon

R1-2007845         Potential enhancements to support NB-IoT and eMTC over satellite      CATT

R1-2008039         Discussion on enhancements for IoT NTN    CMCC

R1-2008200         On Necessary changes to support NB-IoT and eMTC over satellite        Samsung

R1-2008258         Discussion on necessary changes to support NB-IoT/eMTC over NTN  OPPO

R1-2008456         Potential Enhancement for NB-IoT/eMTC over Satellite          Apple

R1-2008855         Discussion on enhancements for IoT-NTN   ZTE

R1-2008921         Enhancement to Support NBIoT and eMTC on NTN  Lenovo, Motorola Mobility

R1-2009008         On enhancements for NB-IoT and eMTC NTN           Intel Corporation

R1-2009043         Necessary changes to support NB-IoT and eMTC over satellite              Xiaomi

R1-2009089         An overview of technical aspects in IoT NTN              Ericsson

R1-2009095         Discussion on RAN1 Aspects of  IoT NTN   MediaTek Inc., Eutelsat

R1-2009115         Necessary changes to support NB-IoT and eMTC over satellite              Qualcomm Incorporated

R1-2009199         On necessary changes to support IoT devices in NTN InterDigital, Inc.

R1-2009216         Necessary changes to support NB-IoT and eMTC over satellite              Nokia, Nokia Shanghai Bell

R1-2009236         Considerations for support of NB-IoT and eMTC over NTN    Sony

8.15.33     Other

R1-2008259         Discussion on other aspects             OPPO

R1-2008320         Other aspects to support IoT in NTN              Huawei, HiSilicon

R1-2008856         Discussion on power consumption and NPRACH capacity for NTN       ZTE

R1-2009090         On evaluation assumptions for eMTC and NB-IoT based NTN Ericsson

 RAN1#104-e

8.15   Study on NB-IoT/eMTC support for Non-Terrestrial Network

Please refer to RP-202689 for detailed scope of the WI

R1-2102199        Session notes for 8.15 (Study on NB-IoT/eMTC support for Non-Terrestrial Network)            Ad-Hoc Chair (Ericsson)

R1-2100599         Rel-17 IoT NTN Work Plan             MediaTek Inc.

R1-2101779         Market expectations for IoT over NTN          NOVAMINT        (rev of R1-2100774)

R1-2101138         Skeleton TR 36.763 Study on NB-IoT/eMTC for NTN (Release 17)      MediaTek Inc.

R1-2101139         Text Proposal for TR 36.673 chapter related to RAN1               MediaTek Inc.

R1-2102177         Text proposal for TR 36.763 for RAN1#104e Agreements       Rapporteur (MediaTek)

R1-2102231         TR36.763 Study on Narrow-Band Internet of Things (NB-IoT) / enhanced Machine Type Communication (eMTC) support for Non-Terrestrial Networks (NTN)       Rapporteur (MediaTek)

Decision: As per email posted on Feb 6^th, more time to check the TR and the TPs by an email discussion post meeting.

8.15.1     Scenarios applicable to NB-IoT/eMTC

R1-2100160         Discussion on scenarios applicable to NB-IoT/eMTC OPPO

R1-2100225         Application scenarios of IoT in NTN             Huawei, HiSilicon

R1-2100248         Discussion on the scenarios and assumption for IoT-NTN        ZTE

R1-2100365         Applicable scenarios to NB-IoT/eMTC         CATT

R1-2100480         Discussion on scenarios applicable to NB-IoT/eMTC for NTN vivo

R1-2100494         Scenarios applicable to NB-IoT/eMTC         Zhejiang Lab

R1-2100521         Discussion on NB-IoT NTN scenarios with small satellites / CubeSats  Sateliot, Gatehouse, Thales, Kepler

R1-2100600         IoT NTN scenarios            MediaTek Inc.

R1-2100874         Scenarios for IoT-NTN     Sony

R1-2100930         On scenarios and evaluations for NB-IoT and eMTC based NTN            Ericsson

R1-2100975         Scenarios applicable to NB-IoT in NTN        Asia Pacific Telecom, FGI

R1-2101019        Feasibility of the large, single-beam small sats / CubeSats scenario  Thales, Sateliot, GateHouse

R1-2101027         Scenarios and evalutions for NB-IoT/eMTC over NTN             Nokia, Nokia Shanghai Bell

R1-2101069         Discussion on scenarios for IoT NTN            CMCC

R1-2101146        IoT NTN Link Budget     Eutelsat S.A.

R1-2101242         On Scenarios applicable to NB-IoT/eMTC   Samsung

R1-2101368         On Link Budget of IoT NTN            Apple

R1-2101413         Discussion on scenarios for NB-IoT and eMTC over NTN       CAICT

R1-2101512         Scenarios applicable to NB-IoT/eMTC         Qualcomm Incorporated

[104-e-NR-NB_IoT_eMTC-01] – Gilles (MediaTek)

Email discussion/approval on enhancements to time and frequency synchronization with checkpoints for agreements on Jan-28, Feb-01, Feb-04

R1-2101802        Summary#1 of AI 8.15.1 Scenarios applicable to NB-IoT/eMTC      Moderator (MediaTek)

R1-2101869        Summary#2 of AI 8.15.1 Scenarios applicable to NB-IoT/eMTC      Moderator (MediaTek)

Decision: From GTW session on Jan 29^th,

Agreement:

The following assumptions are agreed for a common set of link budget parameters:

• UE power class (PC5=20 dBm)
• UE Noise Figure (NF=9 dB)
• Channel Bandwidth for NB-IoT and eMTC as was included in IoT NTN reference scenario parameters agreed in RAN1#103e
• NB-IoT 180 kHz (DL), Up to 180 kHz with all permissible smaller resource allocations 12*15 kHz, 6*15 kHz, 3*15 kHz, 1*15 kHz, 1*3.75 kHz
• eMTC: 1080 kHz (DL), Up to 1080 kHz with all permissible smaller resource allocations, including 2*180 kHz, 180 kHz, 2*15 kHz or 3*15 kHz or 6*15 kHz (UL)

·        Other losses

NOTE 1: With PC3 (23 dBm) there is a 3dB gain compared to the PC5 (20 dBm) assumption on UL.

NOTE 2: With NF=7 dB, there is a 2 dB improvement compare to NF=9 dB on DL.

NOTE 3: Link budgets with other link budget parameters are not excluded from being captured in the TR.

NOTE 4: These parameters are only for the purpose of link budget calculations.

NOTE 5: Atmospheric losses are a function of elevation angle.

R1-2101998        Summary#3 of AI 8.15.1 Scenarios applicable to NB-IoT/eMTC      Moderator (MediaTek)

R1-2102102        Summary#4 of AI 8.15.1 Scenarios applicable to NB-IoT/eMTC      Moderator (MediaTek)

Decision: From GTW session on Feb 4^th,

Agreement:

Link budget analysis assumes 3 dB polarization loss for DL and 3 dB polarization loss on UL for satellite parameters Set 1, Set 2, Set 3, and Set 4

Agreement:

Include in TR 36.763, the 3 dB beam width (HPBW), central beam center elevation and central beam edge elevation in the satellite parameter set(s) to be used in link budget calculations – (Corresponding satellite parameter Set 3 and Set 4 are given in Section 9.4)

NOTE 1: The 3 dB beam width (HPBW) is already included in satellite parameter set 1 and Set 2 in TR 38.821 Table 6.1.1.1-1 and Table 6.1.1.1-2  respectively. The central beam center elevation  for Set-1 and Set-2 is defined as the target elevation angle that is included in in TR 38.821 Table 6.1.3.2-1. The central beam edge satellite-UE distance can be derived from the central beam edge elevation and does not need to be included.

NOTE 2: Central beam center elevation is the beam center elevation of the central beam in the beam layout.

NOTE 3: Central beam edge elevation is the minimum beam edge elevation of the central beam in the beam layout.

NOTE 4 In SLS evaluation with a multiple beam layout, the central beam is the serving beam for UEs. The outer beams have beam center elevation that is different from the central beam center elevation.  For the interference modelling, the interference due to the outer beams is determined by using their respective beam center elevations.

NOTE 5: For the multiple-beam satellite cell, the longest beam edge distance will correspond to the minimum beam edge elevation of the most outer beam as illustrated in figure below.

Agreement:

Include the following tables in TR 36.763:

• Set 1 satellite parameters (based on TR 38.821, Table 6.1.1.1-1)
• Set 2 satellite parameters (based on TR 38.821, Table 6.1.1.1-2)
• Set 3 satellite parameters (Eutelsat R1-2101146 with central beam edge elevation 12.5 degree for GEO, and 30 degree for LEO-600 km and 1200 km)

NOTE 1: This value is equivalent to the antenna diameter in Sec. 6.4.1 of TR 38.811

NOTE 2: Satellite beam diameter is at Nadir point

NOTE 3: Central beam center elevation is referred to as central beam elevation in TR 38.821

NOTE 4: Central beam edge elevation is the minimum beam edge elevation of the central beam in the beam layout.

• Set 4 satellite parameters (Thales, Sateliot, Gatehouse R1-2101019)

NOTE 1: This value is equivalent to the antenna diameter in Sec. 6.4.1 of TR 38.811

NOTE 2: Satellite beam diameter is at Nadir point

NOTE 3: Central beam center elevation is referred to as central beam elevation in TR 38.821

NOTE 4: Central beam edge elevation is the minimum beam edge elevation of the central beam in the beam layout.

Final summary in:

R1-2102265        Summary#5 of AI 8.15.1 Scenarios applicable to NB-IoT/eMTC      Moderator (MediaTek)

8.15.2     Enhancements to time and frequency synchronization

Including random access procedure/signals

R1-2100161         Discussion on enhancements to time and frequency synchronization      OPPO

R1-2100234         Discussion on time and frequency synchronization enhancement for IoT in NTN               Huawei, HiSilicon

R1-2100249         Discussion on the synchronization for IoT-NTN         ZTE

R1-2100366         Time and frequency synchronization for NB-IoT/eMTC           CATT

R1-2100481         Discussion on time and frequency synchronization enhancements on NB-IoT/eMTC for NTN vivo

R1-2100601         UE Time and frequency Synchronisation for IoT NTN              MediaTek Inc.

R1-2100683         On synchronization for NB-IoT and eMTC NTN        Intel Corporation

R1-2100763         Time and frequency synchronization for IoT NTN      Lenovo, Motorola Mobility

R1-2100810         Consideration on enhancements to time and frequency synchronization Spreadtrum Communications

R1-2100875         Time and frequency synchronisation enhancements for IoT-NTN           Sony

R1-2100931         On time and frequency synchronization enhancements for IoT NTN       Ericsson

R1-2100976         Time and frequency synchronization to NB-IoT in NTN           Asia Pacific Telecom, FGI

R1-2101028         Enhancements to time and frequency synchronization for NB-IoT/eMTC over NTN               Nokia, Nokia Shanghai Bell

R1-2101070         Discussion on enhancements for IoT NTN    CMCC

R1-2101105         Discussion on time and frequency synchronization for IoT NTN             Xiaomi

R1-2101243         On enhancements to time and frequency synchronization         Samsung

R1-2101369         Discussion on Time and Frequency Synchronization in IoT NTN            Apple

R1-2101402         Time/Frequency Synchronization for IoT NTN           InterDigital, Inc.

R1-2101513         Enhancements to time and frequency synchronization Qualcomm Incorporated

R1-2101692         Discussion on enhancement of time and frequency synchronization for NB-IoT over satellite Fraunhofer IIS, Fraunhofer HHI

[104-e-NR-NB_IoT_eMTC-02] – Gilles (MediaTek)

Email discussion/approval on enhancements to time and frequency synchronization with checkpoints for agreements on Jan-28, Feb-01, Feb-04

R1-2101803        Summary#1 of AI 8.15.2 Enhancements to time and frequency synchronization               Moderator (MediaTek)

R1-2101870        Summary#2 of AI 8.15.2 Enhancements to time and frequency synchronization               Moderator (MediaTek)

Decision: From GTW session on Jan 29^th,

Agreement:

Study potential impact of GNSS Position fix on UE power consumption using battery life methodology in Rel-13 TR 45.820 (Section 5.4)

FFS: Details of the study

R1-2101999         Summary#3 of AI 8.15.2 Enhancements to time and frequency synchronization               Moderator (MediaTek)

Decision: As per email posted on Feb 3^rd,

Agreement:

Discuss whether GNSS measurement window is needed and beneficial for initial access.

Agreement:

For the study of potential impact of GNSS Position fix on UE power consumption consider at least the following parameters

• GNSS power consumption value
• GNSS position Time To First Fix

R1-2102103        Summary#4 of AI 8.15.2 Enhancements to time and frequency synchronization               Moderator (MediaTek)

Agreement:

Study potential impact of NTN SIB carrying the satellite ephemeris on

• UE power consumption in NB-IoT and eMTC
• Accuracy of satellite location tracking
• PRACH congestion

Agreement:

Study the UE pre-compensation of satellite delay during long UL transmission on (N)PUSCH in NB-IoT and eMTC.

Agreement:

Study the UE pre-compensation of satellite delay and Doppler during long UL transmission on PRACH in NB-IoT and eMTC.

Agreement:

Study the UE pre-compensation of satellite Doppler shift during long UL transmission on (N)PUSCH in NB-IoT and eMTC.

Final summary in:

R1-2102266        Summary#5 of AI 8.15.2 Enhancements to time and frequency synchronization               Moderator (MediaTek)

8.15.3     Timing relationship enhancements

R1-2100162         Discussion on timing relationship enhancements        OPPO

R1-2100235         Discussion on timing relationship enhancement for IoT in NTN              Huawei, HiSilicon

R1-2100250         Discussion on timing relationship for IoT-NTN          ZTE

R1-2100367         Timing relationship enhancement for NB-IoT/eMTC CATT

R1-2100482         Discussion on timing relationship enhancements on NB-IoT/eMTC for NTN       vivo

R1-2100495         Timing relationship enhancements to support NB-IoT/eMTC in Non-Terrestrial Network Zhejiang Lab

R1-2100602         Timing relationship enhancements  MediaTek Inc.

R1-2100684         On timing relationship for NB-IoT and eMTC NTN   Intel Corporation

R1-2100764         Timing relationship enhancements for IoT NTN          Lenovo, Motorola Mobility

R1-2100811         Consideration on timing relationship enhancements   Spreadtrum Communications

R1-2100876         Timing relationship for IoT-NTN    Sony

R1-2100932         On timing relationship enhancements for IoT NTN     Ericsson

R1-2100977         Timing relationship enhancements to NB-IoT in NTN               Asia Pacific Telecom, FGI

R1-2101029         Timing relationship enhancements for NB-IoT/eMTC over NTN            Nokia, Nokia Shanghai Bell

R1-2101106         Discussion on the timing relationship enhancement for IoT NTN            Xiaomi

R1-2101244         On timing relationship enhancements            Samsung

R1-2101370         Discussion on Timing Relationship Enhancement in IoT NTN Apple

R1-2101403         On timing relationship enhancement for IoT NTN       InterDigital, Inc.

R1-2101514         Timing relationship enhancements  Qualcomm Incorporated

[104-e-NR-NB_IoT_eMTC-03] – Sam (Sony)

Email discussion/approval on enhancements to time and frequency synchronization with checkpoints for agreements on Jan-28, Feb-01, Feb-04

R1-2101844        FL summary of AI 8.15.3 Timing relationship for IoT-NTN              Moderator (Sony)

R1-2101949        FL summary#2 of AI 8.15.3          Moderator (Sony)

Decision: From GTW session on Feb 2^nd,

Agreement:

For NB-IoT over NTN, at least the following timing relationships need to be studied individually for checking whether enhancement is necessary and beneficial:

• NPDCCH to NPUSCH format 1
• RAR grant to NPUSCH format 1
• NPDSCH to HARQ-ACK on NPUSCH format 2
• NPDCCH order to NPRACH
• Timing advance command activation
• FFS: Other NB-IoT timing relationships

Agreement:

For eMTC over NTN, at least the following timing relationships can be studied individually for checking whether enhancement is necessary and beneficial:

• MPDCCH to PUSCH
• RAR grant to PUSCH
• PDCCH order to PRACH
• MPDCCH to scheduled uplink SPS
• PUSCH to HARQ-ACK on PUCCH
• CSI reference resource timing
• MPDCCH to aperiodic SRS
• Timing advance command activation
• FFS: Other eMTC timing relationships

Agreement:

Identify IoT-NTN configurations needing activation/de-activation via MAC CE and their timing relationships.

Agreement:

Study the impact of large RTD (which impacts TA) on HD-FDD UL-DL timing relationships and check whether enhancement is necessary and beneficial.

R1-2102174        FL summary#3 of AI 8.15.3          Moderator (Sony)

Decision: As per email posted on Feb 5^th,

Agreement:

Study the impact on any timing relationships for IoT-NTN due to the need to perform GNSS measurements for time and frequency synchronization.

8.15.4     Enhancements on HARQ

R1-2100163         Discussion on HARQ enhancements             OPPO

R1-2100236         Discussion on HARQ enhancement for IoT in NTN    Huawei, HiSilicon

R1-2100251         Discussion on HARQ for IoT-NTN ZTE

R1-2100368         HARQ operation enhancement for NB-IoT/eMTC      CATT

R1-2100483         Discussion on HARQ enhancements on NB-IoT/eMTC for NTN            vivo

R1-2100603         Enhancement on HRQ       MediaTek Inc.

R1-2100685         On HARQ enhancements for NB-IoT and eMTC NTN              Intel Corporation

R1-2100765         HARQ enhancement for IoT NTN   Lenovo, Motorola Mobility

R1-2100812         Consideration on enhancements on HARQ   Spreadtrum Communications

R1-2100877         HARQ issues for IoT-NTN              Sony

R1-2100933         On HARQ enhancements for IoT NTN          Ericsson

R1-2100978         Enhancements on HARQ to NB-IoT in NTN Asia Pacific Telecom, FGI

R1-2101030         HARQ for NB-IoT/eMTC over NTN             Nokia, Nokia Shanghai Bell

R1-2101107         Discussion on the HARQ enhancement for IoT NTN  Xiaomi

R1-2101245         On enhancements on HARQ            Samsung

R1-2101323         NTN IoT HARQ Considerations     Sierra Wireless, S.A.

R1-2101371         Discussion on HARQ Enhancement in IoT NTN         Apple

R1-2101404         HARQ enhancement for IoT NTN   InterDigital, Inc.

R1-2101515         Enhancements on HARQ  Qualcomm Incorporated

[104-e-NR-NB_IoT_eMTC-04] – Carmela (Samsung)

Email discussion/approval on enhancements to time and frequency synchronization with checkpoints for agreements on Jan-28, Feb-01, Feb-04

R1-2101822        Summary#1 for enhancements on HARQ Moderator (Samsung)

Decision: From GTW session on Jan 27^th,

Agreement:

Study further the potential benefits and/or drawbacks of increasing the number of HARQ processes on throughput, latency, power consumption and complexity

Decision: From GTW session on Jan 29^th,

Agreement:

• For NTN, further study potential benefits and/or drawbacks of disabling HARQ feedback for NB-IoT.
• For NTN, further study potential benefits and/or drawbacks of disabling HARQ feedback for eMTC.

Agreement:

In relation to HARQ operation in NTN IoT, further study at least

• The necessity, potential benefits and drawbacks of any other potential HARQ feedback mechanisms
• The necessity, potential benefits and drawbacks of reduced PDCCH monitoring
• The necessity, potential benefits and drawbacks of coverage enhancements
• The necessity, potential benefits and drawbacks of uplink transmission gaps with multiple HARQ processes
• The necessity, potential benefits and drawbacks of maintaining HARQ process continuity in serving cell change
• The necessity, potential benefits and drawbacks of multiple Transport Blocks scheduling
• The necessity, potential benefits and drawbacks of throughput enhancements
• FFS: Whether target throughput in NTN will be the same as target throughput in terrestrial networks

R1-2101956         Summary#2 for enhancements on HARQ      Moderator (Samsung)

R1-2101957        Summary#3 for enhancements on HARQ Moderator (Samsung)

Decision: From GTW session on Feb 2^nd,

Agreement:

The motivation for introducing HARQ enhancements in NR NTN needs further consideration for HARQ enhancements in NTN IoT. Capture the following in the TR:

• For NTN IoT, potential HARQ enhancements need to consider the main characteristics of an IoT device, which are low complexity, low cost, low power consumption and low throughput, and key requirements of IoT services which are extended coverage, delay-tolerant and infrequent data transmissions, and support of massive communications.
• The peak throughput of IoT UEs operating over NTN is not expected to be higher than the peak throughput of IoT UEs operating over TN.

R1-2102132        Summary#4 for enhancements on HARQ Moderator (Samsung)

Agreement:

Further study to identify whether HARQ stalling happens at least in the GEO satellite scenario.

Agreement:

• Further discuss the potential benefits and/or drawbacks of increasing the number of HARQ processes in the UL for NB-IoT and eMTC, and for the analysis consider at least the following for the number of HARQ processes
• NB-IoT: 1,2,4
• eMTC: 2,4,8,14
• And discuss at least power consumption and peak data rate as performance metrics
• FFS: Whether to consider DL
• Other values for number of HARQ processes below the maximum value can be discussed

Agreement:

• Further discuss the potential benefits and/or drawbacks of disabling HARQ feedback for NB-IoT and eMTC, and consider at least the following number of HARQ processes for the analysis
• NB-IoT:

• Total: 2, disabled: {1,2}

• eMTC:

• Total: 2, disabled: {1,2}
• Total: 8, disabled: {1,2,7,8}
• Other values for number of HARQ processes below the maximum value can be discussed
• FFS: whether to consider separately LEO and GEO scenarios
• FFS: whether to allow disabling of HARQ feedback in case of single HARQ process
• FFS: whether to allow disabling of all HARQ feedback
• FFS: other details for the evaluation/analysis

8.15.55     Other

R1-2100164         Discussion on other aspects             OPPO

R1-2100252         Discussion on additional enhancement for IoT-NTN  ZTE

R1-2100604         Others   MediaTek Inc.

R1-2100813         Consideration on other design aspects for IOT NTN   Spreadtrum Communications

R1-2100878         Power consumption of IoT-NTN     Sony

R1-2100934         On evaluation assumptions for NB-IoT and eMTC based NTN Ericsson

R1-2100979         NB-IoT modifications to support the NTN deployment             Asia Pacific Telecom, FGI

R1-2101031         Link budget analysis for UE power class 6 for NB-IoT/eMTC over NTN               Nokia, Nokia Shanghai Bell

R1-2101108         Discussion on the other design aspects for IoT NTN   Xiaomi

R1-2101261         Other aspects to support IoT in NTN              Huawei, HiSilicon

R1-2101516         Other aspects for NTN IOT              Qualcomm Incorporated

 RAN1#104-bis-e

8.15   Study on NB-IoT/eMTC support for Non-Terrestrial Network

Please refer to RP-202689 for detailed scope of the WI

R1-2103987        Session notes for 8.15 (Study on NB-IoT/eMTC support for Non-Terrestrial Network)            Ad-Hoc Chair (Ericsson)

R1-2102753         FS_LTE_NBIOT_eMTC_NTN work plan    MediaTek Inc.

[post-104b-e-NR-NB_IoT_eMTC] - Gilles (MediaTek)

Email discussion/approval on update to TR to capture latest agreements until Apr–26

R1-2103897        Text proposal for TR 36.763 for RAN1#104bis-e Agreements           Moderator (MediaTek)

Decision: As per email decision posted on April 27^th, the document is endorsed.

R1-2104146        Study on Narrow-Band Internet of Things (NB-IoT) / enhanced Machine Type Communication (eMTC) support for Non-Terrestrial Networks (NTN) (Release 17) Rapporteur (MediaTek)

Decision: As per email decision posted on April 27^th, the draft TR 36.763 is endorsed as version v0.2.0.

R1-2104147        Link budget result calibration Spreadsheet for IoT NTN     Rapporteur (MediaTek)

Decision: As per email decision posted on April 27^th, the spreadsheet for link budget calibration is endorsed.

8.15.1     Scenarios applicable to NB-IoT/eMTC

R1-2102343         Application scenarios of IoT in NTN             Huawei, HiSilicon

R1-2102422         Discussion on scenarios applicable to NB-IoT/eMTC OPPO

R1-2102550         Discussion on scenarios applicable to NB-IoT_eMTC for NTN              vivo

R1-2102617         Applicable scenario and initial evaluation result to NB-IoT/eMTC         CATT

R1-2102750         Discussion on NTN-IoT scenario with MEO Hughes/EchoStar

R1-2102754         Scenarios applicable to IoT NTN     MediaTek Inc.

R1-2102831         Link budget evaluations for NB-IoT/eMTC over NTN              Nokia, Nokia Shanghai Bell

R1-2102905         Discussion on scenarios applicable to NB-IoT/eMTC CMCC

R1-2102916         Discussion on the scenarios and assumption for IoT-NTN        ZTE

R1-2102972         Discussion on the link budget of NBIoT and eMTC over NTN Xiaomi

R1-2103060         On scenarios and evaluations for NB-IoT and eMTC based NTN            Ericsson

R1-2103070         Scenarios applicable to NB-IoT/eMTC          Qualcomm Incorporated

R1-2103132         Link Budget Analysis of IoT NTN  Apple

R1-2103266         Initial link budget evaluation for NB-IoT/eMTC         Samsung

R1-2103318         Scenarios for IoT-NTN     Sony

R1-2103716         Link budget analysis for Set-4         Sateliot, Gatehouse, Thales

[104b-e-NR-NB_IoT_eMTC-01] – Gilles (MediaTek)

Email discussion/approval on scenarios applicable to NB-IoT/eMTC with checkpoints for agreements on Apr-15, Apr-20

R1-2103826        Summary #1 of AI 8.15.1 Scenarios applicable to NB-IoT/eMTC Document for: Discussion and Decision                  Moderator (MediaTek)

Agreement:

Capture in TR 36.763 the summary of link budget results from contributing companies in Appendix 1, Section 6.1.1

NOTE 1: The summary in Appendix 1, Section 6.1.1 can be further checked and revised during the drafting of Text Proposal as necessary.

NOTE 2: The summary of link budget results will be captured with alignment between contributing companies

Agreement:

Capture the detailed link budget results from contributing companies in a separate spreadsheet

Agreement:

Capture parameters associated with Set 4 for maximum beam diameter of 1700 km in a separate table in TR 36.763:

NOTE: There is no impact on Table 6.1-1 : IoT NTN reference scenario parameters in TR 36.763

Agreement:

Include the following in TR36.763

Add MEO scenario D in Table 4.2-1 in TR 36.763.

Table 4.2-1: IoT NTN reference scenarios (TR 36.763)

Agreement:

Add MEO IoT NTN reference scenario parameters in Table 6.1-1 in TR 36.763:

Table 6.1-1: IoT NTN reference scenario parameters (TR 36.763)

Agreement:

Include MEO Set-5 parameters for link budget analysis in a new Table 6.2-8 in TR 36.763, as a representative characterization of NTN-IoT scenarios with MEO altitude and characteristics:

Table 6.2-8: Sets of satellite parameters for link budget and system level evaluations

Agreement:

Add MEO Set-5 satellite parameters for system level simulator calibration   in a new Table 6.2-9 in TR 36.763:

Table 6.2-9: Set-5 parameters for link budget analysis

Agreement:

Add observation in TR 36.763:

The doppler shift/variation and the delay variation for MEO are smaller than for LEO. The maximum delay for MEO is smaller than for GEO. The IoT-NTN enhancements for LEO and GEO should be sufficient to support MEO.

NOTE: The parameter set for MEO is only for information/reference and evaluation/enhancements are mainly considered for GEO and LEO. These enhancements can be applicable for MEO.

Final summary in R1-2103962.

8.15.2     Enhancements to time and frequency synchronization

Including random access procedure/signals

R1-2102344         Discussion on time and frequency synchronization enhancement for IoT in NTN               Huawei, HiSilicon

R1-2102423         Discussion on enhancements to time and frequency synchronization      OPPO

R1-2102473         Consideration on enhancements to time and frequency synchronization Spreadtrum Communications

R1-2102618         Time and frequency synchronization for NB-IoT/eMTC           CATT

R1-2102736         Enhancements to time and frequency synchronization Asia Pacific Telecom, FGI, ITRI, III

R1-2102755         Enhancements to time and frequency synchronization for IoT NTN        MediaTek Inc.

R1-2102832         Enhancement to time and frequency synchronization for NB-IoT/eMTC over NTN               Nokia, Nokia Shanghai Bell

R1-2102906         Enhancements to time and frequency synchronization for IoT  NTN       CMCC

R1-2102917         Discussion on the synchronization for IoT-NTN         ZTE

R1-2102973         Discussion on time and frequency synchronization for IoT NTN             Xiaomi

R1-2103056         On synchronization for NB-IoT and eMTC NTN        Intel Corporation

R1-2103061         On time and frequency synchronization enhancements for IoT NTN       Ericsson

R1-2103071         Enhancements to time and frequency synchronization Qualcomm Incorporated

R1-2103133         On Time and Frequency Synchronization in IoT NTN Apple

R1-2103267         On enhancements to time and frequency synchronization         Samsung

R1-2103273         Time/Frequency Synchronization for IoT NTN           InterDigital, Inc.

R1-2103319         Time and frequency synchronisation enhancements for IoT-NTN           Sony

R1-2103528         Time and frequency synchronization for IoT NTN      Lenovo, Motorola Mobility

R1-2102758        Summary #1 of AI 8.15.2  Enhancements to time and frequency synchronization               MediaTek Inc.

[104b-e-NR-NB_IoT_eMTC-02] – Gilles (MediaTek)

Email discussion/approval on enhancements to time and frequency synchronization with checkpoints for agreements on Apr-15, Apr-20

R1-2103908        Summary #3 of AI 8.15.2 Enhancements to time and frequency synchronization               Moderator (MediaTek)

R1-2103950        Summary #3 of AI 8.15.2 Enhancements to time and frequency synchronization               Moderator (MediaTek)

Agreement:

• Capture in TR 36.763, moderator’s summary of GNSS Position fix impact on UE power consumption based on Appendix A Section 5.1
• Capture in TR 36.763, individual companies battery life analysis in Appendix A

Agreement:

UE pre-compensation done per N time units for long PUSCH is the baseline solution.

• The pre-compensation does not vary within a block of N time units
• FFS: the definition and value of N

Agreement:

UE pre-compensation done per N time units for long PRACH is the baseline solution.

• The pre-compensation does not vary within a block of N time units
• FFS: the definition and value of N

Agreement:

For DL synchronization in the Rel-17 timeframe, the following should be considered

• New Channel raster with a step size increased to be greater than 100 kHz
• (part of) ARFCN-indication-in-MIB

Agreement:

Capture the following in the TR:

The required power consumption to read SIB containing satellite ephemeris information for the short sporadic connections use case is not significant.

• Note: For this conclusion, it is assumed that the UE need not read broadcast SIB for the purpose of obtaining satellite ephemeris information in CONNECTED mode.

Final summary in R1-2103964.

8.15.3     Timing relationship enhancements

R1-2102345         Discussion on timing relationship enhancement for IoT in NTN              Huawei, HiSilicon

R1-2102424         Discussion on timing relationship enhancements        OPPO

R1-2102474         Consideration on timing relationship enhancements   Spreadtrum Communications

R1-2102619         Timing relationship enhancement for NB-IoT/eMTC CATT

R1-2102737         Timing relationship enhancements  Asia Pacific Telecom, FGI, ITRI, III

R1-2102756         Timing relationship enhancements for IoT NTN          MediaTek Inc.

R1-2102800         Timing relationship enhancements to support NB-IoT eMTC in Non-Terrestrial Network Zhejiang Lab

R1-2102833         Timing relationship enhancements for NB-IoT/eMTC over NTN            Nokia, Nokia Shanghai Bell

R1-2102907         Timing relationship enhancements  for IoT  NTN        CMCC

R1-2102918         Discussion on timing relationship for IoT-NTN          ZTE

R1-2102974         Discussion on the timing relationship enhancement for IoT NTN            Xiaomi

R1-2103057         On timing relationship for NB-IoT and eMTC NTN   Intel Corporation

R1-2103062         On timing relationship enhancements for IoT NTN     Ericsson

R1-2103072         Timing relationship enhancements  Qualcomm Incorporated

R1-2103134         On Timing Relationship Enhancement in IoT NTN     Apple

R1-2103268         Timing relationship enhancements  Samsung

R1-2103274         Timing relationship enhancement for IoT NTN           InterDigital, Inc.

R1-2103320         Timing relationships for IoT-NTN  Sony

R1-2103529         Timing relationship enhancements for IoT NTN          Lenovo, Motorola Mobility

[104b-e-NR-NB_IoT_eMTC-03] – Sam (Sony)

Email discussion/approval on timing relationship enhancements with checkpoints for agreements on Apr-15, Apr-20

R1-2103847        FL summary #1 of AI 8.15.3 Timing relationship for IoT-NTN         Moderator (Sony)

R1-2103887        FL summary #2 of AI 8.15.3 Timing relationship for IoT-NTN         Moderator (Sony)

R1-2103957        FL summary #3 of AI 8.15.3 Timing relationship for IoT-NTN         Moderator (Sony)

R1-2104083        FL summary #4 of AI 8.15.3: Timing relationship for IoT-NTN       Moderator (Sony)

Agreement:

The following NB-IoT timing relationships need enhancing for essential minimum functionality of IoT NTN:

• NPDCCH to NPUSCH format 1
• RAR grant to NPUSCH format 1
• NPDSCH to HARQ-ACK on NPUSCH format 2
• Timing advance command activation
• FFS: NPDCCH order to NPRACH
• FFS: Other NB-IoT timing relationships

Agreement:

The enhancement based on extending the timing relationship, by e.g. Koffset, adopted in NR NTN should be the starting point for enhancement of NB-IoT timing relationships in IoT NTN. Details can be further discussed considering IoT NTN.

Agreement:

The following eMTC timing relationships need enhancing for essential minimum functionality of IoT NTN:

• MPDCCH to PUSCH
• RAR grant to PUSCH
• MPDCCH to scheduled uplink SPS
• PUSCH to HARQ-ACK on PUCCH
• CSI reference resource timing
• MPDCCH to aperiodic SRS
• Timing advance command activation
• FFS: MPDCCH order to PRACH
• FFS: Other eMTC timing relationships

Agreement:

The enhancement based on extending the timing relationship, by e.g. Koffset, adopted in NR NTN should be the starting point for enhancement of eMTC timing relationships in IoT NTN. Details can be further discussed considering IoT NTN.

Agreement:

For NB-IoT over NTN, the following timing relationship needs to be studied to check whether enhancement is necessary and beneficial:

·        PRACH preamble retransmission

Agreement:

For eMTC over NTN, the following timing relationship needs to be studied to check whether enhancement is necessary and beneficial:

·        PRACH preamble retransmission

Agreement:

Capture the following in the TR:

The UE-specific TA and/or K_offset can be used by the eNB in its scheduling to avoid UL-DL collisions in FDD-HD.

Agreement:

The following aspects of Koffset are not to be studied further and can at least rely on decisions made in the NR NTN WI:

• Explicit or implicit indication in system information
• Support UE-specific Koffset after initial access

8.15.4     Enhancements on HARQ

R1-2102346         Discussion on HARQ enhancement for IoT in NTN    Huawei, HiSilicon

R1-2102425         Discussion on HARQ enhancements             OPPO

R1-2102475         Consideration on enhancements on HARQ   Spreadtrum Communications

R1-2102551         Discussion on HARQ enhancements on NB-IoT/eMTC for NTN            vivo

R1-2102620         HARQ operation enhancement for NB-IoT/eMTC      CATT

R1-2102738         Enhancements on HARQ  Asia Pacific Telecom, FGI, ITRI, III

R1-2102757         Enhancements on HARQ for IoT NTN          MediaTek Inc.

R1-2102834         HARQ for NB-IoT/eMTC over NTN             Nokia, Nokia Shanghai Bell

R1-2102908         Enhancements on HARQ for IoT  NTN         CMCC

R1-2102919         Discussion on HARQ for IoT-NTN ZTE

R1-2102975         Discussion on the HARQ enhancement for IoT NTN  Xiaomi

R1-2103063         On HARQ enhancements for IoT NTN          Ericsson

R1-2103073         Enhancements on HARQ  Qualcomm Incorporated

R1-2103135         On HARQ Enhancement in IoT NTN            Apple

R1-2103269         On enhancements on HARQ            Samsung

R1-2103275         HARQ enhancement for IoT NTN   InterDigital, Inc.

R1-2103321         HARQ issues for IoT-NTN              Sony

R1-2103530         HARQ enhancement for IoT NTN   Lenovo, Motorola Mobility

[104b-e-NR-NB_IoT_eMTC-04] – Carmela (Samsung)

Email discussion/approval on enhancements on HARQ with checkpoints for agreements on Apr-15, Apr-20

R1-2103803        Summary#1 of enhancements on HARQ   Moderator (Samsung)

R1-2103804        Summary#2 of enhancements on HARQ   Moderator (Samsung)

R1-2103805        Summary#3 of enhancements on HARQ   Moderator (Samsung)

From GTW session

Agreement:

Increasing the number of HARQ processes for NB-IoT and for eMTC in NTN is recommended not to be supported in Rel-17.

8.15.55     Other

R1-2102426         Discussion on other aspects             OPPO

R1-2102476         Consideration on other design aspects for IOT NTN   Spreadtrum Communications

R1-2102835         Applicability of NB-IoT/eMTC features for NTN       Nokia, Nokia Shanghai Bell

R1-2102920         Discussion on additional enhancement for IoT-NTN  ZTE

R1-2102976         Discussion on the other design aspects for IoT NTN   Xiaomi

R1-2103064         On evaluation assumptions for NB-IoT and eMTC based NTN Ericsson

R1-2103074         Other aspects for NTN IOT              Qualcomm Incorporated

R1-2103396         Other aspects to support IoT in NTN              Huawei, HiSilicon

 RAN1#105-e

8.15   Study on NB-IoT/eMTC support for Non-Terrestrial Network

Please refer to RP-202689 for detailed scope of the WI

R1-2106237        Session notes for 8.15 (Study on NB-IoT/eMTC support for Non-Terrestrial Network)            Ad-Hoc Chair (Ericsson)

R1-2104573         Link budget result calibration Spreadsheet for IoT NTN            MediaTek Inc.

R1-2105815        Study on Narrow-Band Internet of Things (NB-IoT) / enhanced Machine Type Communication (eMTC) support for Non-Terrestrial Networks (NTN) (Release 17)         Rapporteur (MediaTek)

Decision: The updated TR 36.763 V0.3.0 is endorsed in GTW session as basis for further updates.

As per email posted on May 27^th, [105-e-NR-NB_IoT_eMTC-01] thread was extended until Tuesday, June 1 to finalize the TR.

R1-2106379        Study on Narrow-Band Internet of Things (NB-IoT) / enhanced Machine Type Communication (eMTC) support for Non-Terrestrial Networks (NTN) (Release 17) Rapporteur (MediaTek)

TR 36.763 V0.4.0 including RAN1#105-e outcomes.

Decision: As per email decision posted on June 3^rd, the updated TR 36.763 V0.4.0 is endorsed and shall be used to prepare v1.0.0 for one step approval in RAN#92-e.

8.15.1     Scenarios applicable to NB-IoT/eMTC

R1-2104571        Summary #1 of AI 8.15.1  Scenarios applicable to NB-IoT/eMTC    Moderator (MediaTek)

R1-2104258         Application scenarios of IoT in NTN             Huawei, HiSilicon

R1-2105946         Discussion on eMTC enabling High Value NTN IoT use-cases Omnispace           (rev of R1-2104403)

R1-2104503         Applicable scenarios to NB-IoT/eMTC         CATT

R1-2104567         Scenarios applicable to IoT NTN     MediaTek Inc.

R1-2104636         Discussion on scenarios applicable to NB-IoT/eMTC CMCC

R1-2104777         Discussion on scenarios applicable to NB-IoT/eMTC OPPO

R1-2104814         On scenarios and evaluations for NB-IoT and eMTC based NTN            Ericsson

R1-2104822         Scenarios applicable to NB-IoT/eMTC          Qualcomm Incorporated

R1-2105138         On Link Budget Analysis of IoT NTN           Apple

R1-2105182         IoT-NTN Link Budgets     Sony

R1-2105193         Discussion on the remaining issues of scenarios and assumption for IoT-NTN     ZTE

R1-2105345         Initial link budget evaluation for NB-IoT/eMTC         Samsung

R1-2105404         Link budget evaluations and deployment for NB-IoT/eMTC over NTN Nokia, Nokia Shanghai Bell

[105-e-NR-NB_IoT_eMTC-01] – Gilles (MediaTek)

Email discussion/approval on scenarios applicable to NB-IoT/eMTC with checkpoints for agreements on May 24, May 27

R1-2106190        Summary #2 of AI 8.15.1 Scenarios applicable to NB-IoT/eMTC     Moderator (MediaTek)

Decision: As per email decision posted on May 27^th,

Agreement:

·        Include the following Table for Set 5 – MEO in TR 36.763

·        Include MEO case 11 in calibration spreadsheet.

Set 5

Agreement:

·        Add other losses as follows for MEO in Table 6.2-1: Other losses in TR 36.763

Table 6.2-1: Satellite losses

NOTE 1: With PC3 (23 dBm) there is a 3dB gain compared to the PC5 (20 dBm) assumption on UL.

NOTE 2: With NF=7 dB, there is a 2 dB improvement compare to NF=9 dB on DL.

NOTE 3: Link budgets with other link budget parameters are not excluded from being captured in the TR.

NOTE 4: These parameters are only for the purpose of link budget calculations.

NOTE 5: Atmospheric losses are a function of elevation angle.

Agreement:

·        Prioritize standalone deployment for NB-IoT / eMTC for support in Rel-17 timeframe.

8.15.2     Enhancements to time and frequency synchronization

Including random access procedure/signals

R1-2104572        Summary #1 of AI 8.15.2 Enhancements to time and frequency synchronization               Moderator (MediaTek)

R1-2104259         Discussion on time and frequency synchronization enhancement for IoT in NTN               Huawei, HiSilicon

R1-2104399         Discussion on enhancements to time and frequency synchronization on NB-IoT_eMTC for NTN           vivo

R1-2104448         Consideration on enhancements to time and frequency synchronization for IoT NTN               Spreadtrum Communications

R1-2104504         Time and frequency synchronization for NB-IoT/eMTC           CATT

R1-2104568         Enhancements to time and frequency synchronization for IoT NTN        MediaTek Inc.

R1-2104637         Enhancements to time and frequency synchronization for IoT NTN        CMCC

R1-2104778         Discussion on enhancements to time and frequency synchronization      OPPO

R1-2104815         On time and frequency synchronization enhancements for IoT NTN       Ericsson

R1-2104823         Enhancements to time and frequency synchronization Qualcomm Incorporated

R1-2104937         On synchronization for NB-IoT and eMTC NTN        Intel Corporation

R1-2105139         Time and Frequency Synchronization in IoT NTN      Apple

R1-2105183         Enhancements to time and frequency synchronisation for IoT-NTN       Sony

R1-2105194         Discussion on the synchronization for IoT-NTN         ZTE

R1-2105346         On enhancements to time and frequency synchronization         Samsung

R1-2105405         Enhancement to time and frequency synchronization for NB-IoT/eMTC over NTN               Nokia, Nokia Shanghai Bell

R1-2105551         Discussion on time and frequency synchronization for IoT NTN             Xiaomi

R1-2105624         Time and frequency synchronization for IoT NTN      Lenovo, Motorola Mobility

R1-2105676         Time/Frequency Synchronization for IoT NTN           InterDigital, Inc.

R1-2105825         Time and Frequency Synchronization to NB-IoT in NTN          Asia Pacific Telecom, FGI

[105-e-NR-NB_IoT_eMTC-02] – Gilles (MediaTek)

Email discussion/approval on enhancements to time and frequency synchronization with checkpoints for agreements on May 25, May 27

R1-2106095        Summary #2 of AI 8.15.2 Enhancements to time and frequency synchronization               Moderator (MediaTek)

From GTW session:

Agreement:

• A specification change is needed for UL transmission with repetitions R>1.
• For segmented UE pre-compensation how the following is handled can be further discussed
• Phase discontinuity at subframe boundary when applying new pre-compensation
• Coherence time limitation due to delay/frequency drift rate during segment
• Signal overlapping between different TA segments
• FFS: Need for more frequent new UL gaps during long transmission
• FFS: Whether sampling frequency adjustment to avoid new UL gaps can be achieved by implementation
• FFS: Value of N for the number of time units and what is the time unit for the segmented UE pre-compensation

Agreement:

A validity timer for UL synchronization (e.g., for satellite ephemeris and potentially other aspects) configured by the network is recommended.

• Details e.g. when to set/reset the timer, timer duration and UE behaviour upon timer expiry can be discussed in the normative phase

Agreement:

For sporadic short transmission:

• The idle UE wakes up from idle DRX / PSM, access the network, perform uplink and/or downlink communications for a short duration of time and go back to idle.
• Before accessing the network, the UE acquires GNSS position fix and does not need to re-acquire a GNSS position fix for the transmission of the packets.

Details of the duration of the short transmission, acquisition of the GNSS position and validity of the GNSS position can be discussed in normative phase.

Agreement:

Capture in Section 8 in TR 36.763 the recommendations for NB-IoT and eMTC NTN Time and frequency synchronization enhancements in Release 17 timeframe can follow NTN NR agreements as baseline for the following:

• UE Pre-compensation including Ephemeris Format (orbital / Position -Velocity)
• Timing Advance T_TA formula (granularity of the timing advance may be different)
• FFS: UE pre-compensation for UL synchronization in RRC_IDLE and RRC_INACTIVE and RRC_CONNECTED states based at least on its GNSS-acquired position and the serving satellite ephemeris
• Combination of Open (i.e. UE autonomous TA estimation, and common TA estimation) and Closed TA (i.e., received TA commands) control loops in RRC_CONNECTED state

NOTE 1: The above is up to the decision in NR-NTN WI

NOTE 2: The NR NTN WI enhancements for UE pre-compensation do not include IoT NTN specific aspects for long transmission on PUSCH and PRACH.

R1-2106191        Summary #3 of AI 8.15.2 Enhancements to time and frequency synchronization               Moderator (MediaTek)

From GTW session:

Agreement:

·        Capture in Section 8 in TR 36.763 the recommendations for NB-IoT and eMTC NTN Time and frequency synchronization enhancements in Release 17 timeframe can follow NTN NR agreements as baseline for the following:

o   UE pre-compensation for UL synchronization in RRC_IDLE and RRC_INACTIVE and RRC_CONNECTED states based at least on its GNSS-acquired position and the serving satellite ephemeris

NOTE 3: The NR NTN WI enhancements for UE pre-compensation do not include:

o   Restriction on the use of GNSS module, where simultaneous GNSS and NTN NB-IoT/eMTC operation is not assumed.

o   IoT NTN aspects of validity timer for UL synchronization and GNSS measurement for sporadic short transmission.

NR NTN have different requirements than IoT NTN for cost, complexity, power consumption, and IoT-specific scenarios.

NOTE 4: It is assumed baseline functions in NB-IoT/eMTC terrestrial work without enhancement unless certain issue is found, that will require essential enhancements

Agreement:

·        With a GNSS position fix that can be assumed to be valid for some period of time X, the following apply for UE in RRC_CONNECTED

o   TA error due to UE velocity satisfies the requirements defined in RAN4

o   Doppler shift error due to UE velocity satisfies the requirement defined in RAN4

·        FFS: Validity of a GNSS position fix and details of acquiring a GNSS position fix, value of X, in RRC CONNECTED mode

·        FFS: Potential impact on the existing closed loop TA maintenance mechanism

·        NOTE: The detailed requirement will be defined in RAN4 during normative work.

Conclusion:

The potential issue of RACH congestion is not to be studied further within Release-17 timeframe.

Final summary in:

R1-2106289        Summary #4 of AI 8.15.2 Enhancements to time and frequency synchronization               Moderator (MediaTek)

8.15.3     Timing relationship enhancements

R1-2104260         Discussion on timing relationship enhancement for IoT in NTN              Huawei, HiSilicon

R1-2104449         Consideration on timing relationship enhancements for IoT NTN           Spreadtrum Communications

R1-2104505         Timing relationship enhancement for NB-IoT/eMTC CATT

R1-2104569         Timing relationship enhancements for IoT NTN          MediaTek Inc.

R1-2104638         Timing relationship enhancements for IoT NTN          CMCC

R1-2104779         Discussion on timing relationship enhancements        OPPO

R1-2104816         On timing relationship enhancements for IoT NTN     Ericsson

R1-2104824         Timing relationship enhancements  Qualcomm Incorporated

R1-2104938         On timing relationship for NB-IoT and eMTC NTN   Intel Corporation

R1-2105140         Timing Relationship Enhancement in IoT NTN           Apple

R1-2105184         Timing relationship enhancements for IoT-NTN         Sony

R1-2105195         Discussion on timing relationship for IoT-NTN          ZTE

R1-2105347         Timing relationship enhancements  Samsung

R1-2105406         Timing relationship enhancements for NB-IoT/eMTC over NTN            Nokia, Nokia Shanghai Bell

R1-2105503         RAR Window Offset         Fraunhofer IIS / Fraunhofer HHI

R1-2105552         Discussion on the timing relationship enhancement for IoT NTN            Xiaomi

R1-2105677         Timing relationship enhancement for IoT NTN           InterDigital, Inc.

R1-2105826         Timing relationship enhancements to NB-IoT in NTN               Asia Pacific Telecom, FGI

[105-e-NR-NB_IoT_eMTC-03] – Sam (Sony)

Email discussion/approval on timing relationship enhancements with checkpoints for agreements on May 24, May 27

R1-2106080        FL summary #1 of AI 8.15.3: Timing relationships for IoT-NTN      Moderator (Sony)

From GTW session:

Agreement:

Make a TP to correct error in TR to:

------ TP -------------

The following eMTC timing relationships need enhancing for essential minimum functionality of IoT NTN:

·        MPDCCH to PUSCH

·        RAR grant to PUSCH

·        MPDCCH to scheduled uplink SPS

·        PDSCH to HARQ-ACK on PUCCH

·        CSI reference resource timing

·        MPDCCH to aperiodic SRS

·        Timing advance command activation

·        FFS: MPDCCH order to PRACH

·        FFS:Other eMTC timing relationships

------ End TP ------------

Conclusion:

The description of timing relationships for eMTC and NB-IoT in Rel-16 do not take the TA into account in general.

• Note: Exceptions to this may be identified as work on eMTC and NB-IoT over NTN progresses further.

R1-2106189        FL summary #2 of AI 8.15.3: Timing relationships for IoT-NTN      Moderator (Sony)

From GTW session:

Agreement:

The RAR window offset value for NR NTN, the parameters used for its calculation and how these are configured or signalled together form a starting point for IoT NTN.

Agreement:

Capture the following in the TR:

Signalling aspects involved in UE-specific TA maintenance and reporting in Rel-17 IoT and techniques to reduce the signalling load have been discussed. Mechanisms to report the UE-specific TA and other means of determining the UE-specific TA have been discussed. Decisions on these aspects can be made during a subsequent normative phase.

R1-2106310        FL summary #3 of AI 8.15.3: Timing relationships for IoT-NTN      Moderator (Sony)

From GTW session:

Agreement:

Capture the following in the TR:

Whether UE-specific K-Offsets are needed or not in Rel17 IoT NTN from a physical layer point of view was discussed but without arriving at a consensus. This issue can be further discussed during a future normative phase.

8.15.4     Enhancements on HARQ

R1-2104261         Discussion on HARQ enhancement for IoT in NTN    Huawei, HiSilicon

R1-2104400         Discussion on HARQ enhancements on NB-IoT_eMTC for NTN           vivo

R1-2104450         Consideration on enhancements on HARQ for IoT NTN           Spreadtrum Communications

R1-2104506         HARQ operation enhancement for NB-IoT/eMTC      CATT

R1-2104570         Enhancements on HARQ for IoT NTN          MediaTek Inc.

R1-2104639         Enhancements on HARQ for IoT NTN          CMCC

R1-2104780         Discussion on HARQ enhancements             OPPO

R1-2104817         On HARQ enhancements for IoT NTN          Ericsson

R1-2104825         Enhancements on HARQ  Qualcomm Incorporated

R1-2105141         HARQ Enhancement in IoT NTN    Apple

R1-2105185         HARQ enhancements for IoT-NTN Sony

R1-2105196         Discussion on HARQ for IoT-NTN ZTE

R1-2105348         On enhancements on HARQ            Samsung

R1-2105407         HARQ for NB-IoT/eMTC over NTN             Nokia, Nokia Shanghai Bell

R1-2105553         Discussion on the HARQ enhancement for IoT NTN  Xiaomi

R1-2105621         HARQ enhancement for IoT NTN   Lenovo, Motorola Mobility

R1-2105678         HARQ enhancement for IoT NTN   InterDigital, Inc.

R1-2105827         Enhancements on HARQ to NB-IoT in NTN Asia Pacific Telecom, FGI

[105-e-NR-NB_IoT_eMTC-04] – Carmela (Samsung)

Email discussion/approval on enhancements on HARQ with checkpoints for agreements on May 25, May 27

R1-2106060        Summary#1 of enhancements on HARQ   Moderator (Samsung)

From GTW session:

Conclusion:

For NB-IoT and eMTC in NTN, RAN1 has not reached consensus to recommend enhancements to the Rel-16 procedure for the monitoring of a PDCCH which indicates an ACK/NACK after transmission of a PUSCH.

Agreement:

Capture the following in the TR:

• RAN1 discussed that if there are a large number of repetitions in NTN IoT, an UL/DL transmission may potentially have a duration larger than the time interval needed by the UE for cell reselection or handover. This may potentially be an issue especially for LEO satellite due to high mobility. Some repetitions may not be able to be transmitted before a cell change happens and this will cause a waste of resources. Combining repetitions from different cells is a potential solution.
• RAN1 has not reached consensus to recommend solutions in Rel-17.

Agreement:

Capture the following in the TR:

• RAN1 discussed to enable PDCCH monitoring during the time period between receiving NPDSCH and transmitting HARQ ACK in NB-IoT to enhance throughput.
• RAN1 has not reached consensus to recommend solutions to enhance throughput in Rel-17.

R1-2106061        Summary#2 of enhancements on HARQ   Moderator (Samsung)

From GTW session:

Conclusion:

From a physical layer perspective, there is no consensus on disabling HARQ feedback for NTN IoT in Rel-17.

R1-2106271        Summary#3 of enhancements on HARQ   Moderator (Samsung)

From GTW session:

Agreement:

Capture the following in the TR:

RAN1 discussed the monitoring of a PDCCH which indicates an ACK/NACK after transmission of a PUSCH. The reason for not monitoring PDCCH for a time period after transmission of the PUSCH is UE power saving.

• When a UE is configured with one HARQ process, it was discussed whether the UE can stop PDCCH monitoring after a PUSCH transmission as a new grant would not be received until after one RTT, or the UE cannot stop PDCCH monitoring because a new grant can be received before one RTT has passed and/or the UE may need to monitor DCI for other scheduling assignments e.g. paging, system information, etc.
• When a UE is configured with two (or more) HARQ processes, whether to stop monitoring PDCCH for a time period after transmission of the PUSCH needs also to consider the relative timing of the two HARQ processes.

RAN1 noted that reduced monitoring of PDCCH is closely related to DRX and should therefore be discussed in RAN1 and RAN2.

Conclusion:

For NB-IoT and eMTC in NTN, RAN1 concluded that enhancements to the Rel-16 procedure for the monitoring of a PDCCH which indicates an ACK/NACK after transmission of a PUSCH is not an essential feature for NTN IoT in Rel-17.

Agreement:

Capture the following in the TR:

RAN1 discussed reporting of additional information by a UE (such as timing information to inform the network that a sufficient number of repetitions has been transmitted, requested number of repetition, BLER-based triggering or bundling of feedback, buffer status, enabling/disabling HARQ feedback, etc.)

Conclusion:

RAN1 concluded that reporting of additional feedback is not an essential feature for NTN IoT in Rel-17.

Final summary in:

R1-2106337        Summary#4 of enhancements on HARQ   Moderator (Samsung)

8.15.55     Other

R1-2104451         Consideration on other design aspects for IoT NTN    Spreadtrum Communications

R1-2104781         Discussion on other aspects             OPPO

R1-2104820         On evaluation assumptions for NB-IoT and eMTC based NTN Ericsson

R1-2104826         Other aspects for NTN IOT              Qualcomm Incorporated

R1-2105197         Discussion on additional enhancement for IoT-NTN  ZTE

R1-2105408         Applicability of NB-IoT/eMTC features for NTN       Nokia, Nokia Shanghai Bell

R1-2105530         Other aspects to support IoT in NTN              Huawei, HiSilicon

R1-2105554         Discussion on the other design aspects for IoT NTN   Xiaomi

 RAN1#106-e

8.15   NB-IoT/eMTC support for Non-Terrestrial Network

Please refer to RP-211601 for detailed scope of the WI

R1-2108613        Session notes for 8.15 (Study on NB-IoT/eMTC support for Non-Terrestrial Network)            Ad-Hoc Chair (Ericsson)

R1-2108215        LTE_NBIOT_eMTC_NTN work plan       Rapporteur (MediaTek)

8.15.1     Enhancements to time and frequency synchronization

R1-2106485         Discussion on time and frequency synchronization enhancement for IoT in NTN               Huawei, HiSilicon

R1-2106633         Discussion on time and frequency synchronization enhancements for NB-IoT/eMTC over NTN             vivo

R1-2106719         Discussion on enhancements to time and frequency synchronization for IOT NTN               Spreadtrum Communications

R1-2106760         Enhancements to time and frequency synchronization Qualcomm Incorporated

R1-2106823         Enhancement to time synchronisation for IoT-NTN    Sony

R1-2106920         On enhancements to time and frequency synchronization         Samsung

R1-2106953         Time and frequency synchronization enhancement for IoT over NTN    CATT

R1-2107018         Enhancements to time and frequency synchronization NEC

R1-2107047         On enhancements to time and frequency synchronization         Nordic Semiconductor ASA

R1-2107067         Enhancements to time and frequency synchronization for IoT NTN        MediaTek Inc.

R1-2107173         Enhancement to time and frequency synchronization for NB-IoT/eMTC over NTN               Nokia, Nokia Shanghai Bell

R1-2107247         Discussion on enhancements to time and frequency synchronization      OPPO

R1-2107291         Enhancements to time and frequency synchronization to NB-IoT NTN  FGI, Asia Pacific Telecom, III, ITRI

R1-2107430         Enhancements on time and frequency synchronization for IoT NTN       CMCC

R1-2107619         On synchronization for NB-IoT and eMTC NTN        Intel Corporation

R1-2107659         On time and frequency synchronization enhancements for IoT NTN       Ericsson

R1-2107772         On Time and Frequency Synchronization in IoT NTN Apple

R1-2107779         Discussion on synchronization for IoT-NTN ZTE

R1-2107909         Discussion on time and frequency synchronization for IoT NTN             Xiaomi

R1-2107942         Time and frequency synchronization for IoT NTN      Lenovo, Motorola Mobility

R1-2108038         On Time/Frequency Synchronization for IoT NTN     InterDigital, Inc.

R1-2108095         Application scenarios of IoT in NTN             GDCNI

[106-e-NR-NB_IoT_eMTC-01] – Gilles (MediaTek)

Email discussion/approval on enhancements to time and frequency synchronization with checkpoints for agreements on August 19, 24 and 27

R1-2107069        Summary #1 of AI 8.15.1  Enhancements to time and frequency synchronization for IoT NTN       MediaTek Inc.

From GTW session:

Agreement:

The following agreements from NR NTN are re-used for IoT NTN as working assumption.

a)      The Doppler shift over the feeder link and any transponder frequency error for both Downlink and Uplink is compensated by the GW and satellite-payload without any specification impacts in Release 17.

b)      The orbital propagator model to be used at UE side can be left to implementation

c)      Timing Advance formula can be transposed to IoT-NTN with T_s used instead of T_c

The Timing Advance applied by an NR NTN UE in RRC_IDLE/INACTIVE and RRC_CONNECTED is given by:

Where:

·          is defined as 0 for PRACH and updated based on TA Command field in msg2/msgB and MAC CE TA command.

o   FFS: details of N_TA update/accumulation.

·          is UE self-estimated TA to pre-compensate for the service link delay.

·         is network-controlled common TA, and may include any timing offset considered necessary by the network.

·         with value of 0 is supported.

o   FFS:  details of signaling including granularity.  

·         is a fixed offset used to calculate the timing advance. 

Note-1: Definition of  is different from that in RAN1#103-e agreement in NR NTN WI. 

Note-2: UE might not assume that the RTT between UE and gNB is equal to the calculated TA for Msg1/Msg A.

Note-3:  is the common timing offset X as agreed in RAN1 #103-e in NR NTN WI.

d)      Support the delivery of ephemeris information using both ephemeris formats, i.e., state vectors and orbital elements

·        Set 1: Satellite position and velocity state vectors (position/velocity)

o   Position X,Y,Z in ECEF (m) 

o   Velocity VX,VY,VZ in ECEF (m/s)

·        Set 2: Parameters in orbital parameter ephemeris format

o   Semi-major axis α [m]

o   Eccentricity e

o   Argument of periapsis ω [rad]

o   Longitude of ascending node Ω [rad]

o   Inclination i [rad]

o   Mean anomaly M [rad] at epoch time to

o   FFS: Whether pre-provisioned ephemeris based on orbital elements can be used as reference. Thereby, only delta corrections can be broadcast in order to reduce the overhead

e)      For TA update in RRC_CONNECTED state, combination of both open (i.e. UE autonomous TA estimation, and common TA estimation) and closed (i.e., received TA commands) control loops shall be supported for IoT-NTN

R1-2108338        Summary #2 of AI 8.15.1  Enhancements to time and frequency synchronization for IoT NTN       Moderator (MediaTek Inc.)

From GTW session:

Agreement:

• Satellite ephemeris read on SIB are valid for the duration of sporadic short transmission in RRC_CONNECTED.
• Common TA parameters if indicated and read on SIB are valid for the duration of sporadic short transmission in RRC_CONNECTED.
• Note: The duration of the short transmission is no longer than the “validity timer for UL synchronization” referred to in the WID objective (but which still needs further discussion for specifying further details)

Agreement:

For sporadic short transmission, UE in RRC_CONNECTED should go back to idle mode and re-acquire a GNSS position fix if GNSS becomes outdated.

R1-2108348        Summary #3 of AI 8.15.1  Enhancements to time and frequency synchronization for IoT NTN       Moderator (MediaTek Inc.)

From GTW session:

Agreement:

Duration of UL transmission segment for UE pre-compensation for PRACH transmission is a number of RACH repetition units configured by the network

·        For NB-IoT, repetition unit is P symbol groups.

·        For eMTC, repetition unit is one preamble including guard period.

·        FFS: Configuration details

Agreement:

Duration of UL transmission segment for UE pre-compensation for PUSCH transmission is a number of PUSCH repetition units configured by the network

·        For NB-IoT, repetition unit is  

·        For eMTC, repetition unit is   for sub-PRB allocation, where T_slot = 0.5 ms. For full-PRB allocation, repetition unit is one subframe.

·        NOTE1:  are defined in TS 36.211 10.1.2.3 and 10.1.3.6 for NB-IoT

·        NOTE2: M_^UL_slot is defined in TS 36.211, 5.2.3A for eMTC

·        FFS: RAN1 to further discuss valid and invalid subframes

·        FFS: Configuration details

R1-2108430        Summary #4 of AI 8.15.1  Enhancements to time and frequency synchronization for IoT NTN       Moderator (MediaTek Inc.)

From GTW session:

Agreement:

For NB-IoT, if a mapping to N_slots slots or a repetition of the mapping in an UL transmission segment for UE pre-compensation for NPUSCH transmission contains a resource element which overlaps with any configured NPRACH resource, the NPUSCH transmission in overlapped N_slots slots is postponed until the next N_slots slots not overlapping with any configured NPRACH resource.

·        NOTE: N_slots is defined in TS 36.211, 10.1.3.6

Agreement:

The UL transmission segment duration is configured by the network

• FFS: Details of the configuration signalling.

Agreement:

The validity timer of UL synchronization is configured by the network

• FFS: Whether a single validity timer or separate validity timers are used for satellite ephemeris and common TA parameters

Agreement:

UE in RRC_IDLE reads the satellite ephemeris on SIB and the common TA parameters if indicated on SIB and (re-)start the validity timer(s) for UL synchronization before moving to RRC_CONNECTED.

• FFS: Details of the precise (re-)start time for the validity timer for UL synchronization to ensure a common understanding between gNB and UE.
• Other signaling details for validity timer are up to RAN2

R1-2108516        Summary #5 of AI 8.15.1  Enhancements to time and frequency synchronization for IoT NTN       Moderator (MediaTek Inc.)

From GTW session:

Agreement:

• For NB-IoT NTN, the network configures one of K values for the UL transmission segment duration of each PRACH preamble format in a k-bit field, where the size of the k-bit field and the number of K candidate values depend on the preamble format.

o   Format 0 and format 1: 3-bit field, K=6 candidate values 2.4.(T_CP+T_SEQ), 4.4.(T_CP+T_SEQ), 8.4.(T_CP+T_SEQ), 16.4.(T_CP+T_SEQ), 32.4.(T_CP+T_SEQ), 64.4.(T_CP+T_SEQ)

o   Format 2:  2-bit field, K=4 candidate values 2.6.(T_CP+T_SEQ), 4.6.(T_CP+T_SEQ), 8.6.(T_CP+T_SEQ), 16.6.(T_CP+T_SEQ) 

• FFS: Down scoping of K candidate values, size of k-bit field
• FFS: Whether the same segment duration can be used for all preambles within a preamble format

Agreement:

For eMTC, the network configures one of K values for the UL transmission segment duration of PRACH in a k-bit field.

·        FFS: K candidate values, size of k-bit field

Agreement:

• For NB-IoT/eMTC NTN, the network configures one of K candidate values for the UL transmission segment duration of NPUSCH/PUSCH in a k-bit field.

o   For NB-IoT, maximum 3-bit field with a maximum number of K=8 candidate values 2 ms, 4 ms, 8 ms, 16 ms, 32 ms, 64 ms, 128 ms, 256 ms 

• FFS: Down scoping of K candidate values, size of k-bit field

Agreement:

• The UL transmission segment duration is provided by UE-specific RRC signalling or by signalling in SIB.
• NOTE: the values of UL transmission segment duration for NB-IoT can be different to those for eMTC

R1-2108558        Summary #6 of AI 8.15.1  Enhancements to time and frequency synchronization for IoT NTN       Moderator (MediaTek Inc.)

From GTW session:

Agreement:

The following agreement from NR NTN are re-used for IoT NTN as working assumption

·        In Rel-17 IoT-NTN, at least support UE which can compute timing advance and frequency adjustment for serving link based on its GNSS position and serving satellite ephemeris signalled by the network and apply corresponding timing advance and frequency adjustment in RRC_IDLE and RRC_CONNECTED modes

·        Serving satellite ephemeris Epoch time is implicitly known as a reference time defined by the starting time of a DL slot and/or frame.

o   FFS: Whether this starting time is given by predefined rule or it is indicated by the Network

Final summary in R1-2108640.

8.15.2     Timing relationship enhancements

R1-2106486         Discussion on timing relationship enhancement for IoT in NTN              Huawei, HiSilicon

R1-2106634         Discussion on timing relationship enhancements for NB-IoT/eMTC over NTN   vivo

R1-2106720         Discussion on timing relationship enhancements for IOT NTN Spreadtrum Communications

R1-2106761         Timing relationship enhancements  Qualcomm Incorporated

R1-2106824         Timing relationship enhancements for IoT-NTN         Sony

R1-2106921         Timing relationship enhancements  Samsung

R1-2106954         Timing relationship enhancement for IoT over NTN   CATT

R1-2107048         On timing relationship enhancements            Nordic Semiconductor ASA

R1-2107068         Timing relationship enhancements for IoT NTN          MediaTek Inc.

R1-2107174         Timing relationship enhancements for NB-IoT/eMTC over NTN            Nokia, Nokia Shanghai Bell

R1-2107248         Discussion on timing relationship enhancements        OPPO

R1-2107292         Timing relationship enhancements to NB-IoT NTN    FGI, Asia Pacific Telecom, III, ITRI

R1-2107431         Discussion on timing relationship enhancements for IoT NTN CMCC

R1-2107620         On timing relationship for NB-IoT and eMTC NTN   Intel Corporation

R1-2107660         On timing relationship enhancements for IoT NTN     Ericsson

R1-2107773         On Timing Relationship Enhancements in IoT NTN   Apple

R1-2107780         Discussion on timing relationship for IoT-NTN          ZTE

R1-2107910         Discussion on the timing relationship enhancement for IoT NTN            Xiaomi

R1-2107943         Timing Relationship for IoT NTN   Lenovo, Motorola Mobility

R1-2108039         On Timing relationship enhancement for IoT NTN     InterDigital, Inc.

[106-e-NR-NB_IoT_eMTC-02] – Sam (Sony)

Email discussion/approval on timing relationship enhancements with checkpoints for agreements on August 19, 24 and 27

R1-2108312         FL summary 1 of AI 8.15.2 Timing relationship for IoT-NTN  Moderator (Sony)

R1-2108350         FL summary 2 of AI 8.15.2 Timing relationship for IoT-NTN  Moderator (Sony)

R1-2108397        FL summary 3 of AI 8.15.2 Timing relationship for IoT-NTN           Moderator (Sony)

From GTW session:

Agreement:

For NB-IoT, on receiving UL grant on DCI format N0 in subframe n, NPUSCH Format 1 is transmitted with a delay of Koffset as compared to transmission as per current specification.

R1-2108493        FL summary 4 of AI 8.15.2 Timing relationship for IoT-NTN           Moderator (Sony)

From GTW session:

Agreement:

For NB-IoT, on receiving a NPDSCH with a RAR message that ends in subframe n, the corresponding Msg3 is transmitted on NPUSCH format 1, with a delay of Koffset as compared to transmission as per current specification.

Agreement:

For NB-IoT, a UE upon detection of a NPDSCH transmission for which it should provide an ACK/NACK feedback, shall transmit the HARQ ACK/NACK with a delay of Koffset as compared to transmission as per current specification.

Agreement:

For NB-IoT, on receiving a timing advance command ending in DL subframe n, the corresponding adjustment of the uplink transmission timing by the received time advance shall be delayed by Koffset as compared to current specification.

Agreement:

For eMTC, on receiving an UL grant via MPDCCH that ends in DL subframe n, PUSCH is transmitted with a delay of Koffset as compared to transmission as per current specification.

Agreement:

For eMTC, on receiving a RAR in a PDSCH that ends in subframe n, PUSCH for Msg3 is transmitted with a delay of Koffset as compared to transmission as per current specification.

Agreement:

For eMTC, when an MPDCCH ending in subframe n activates UL SPS, the time of the first subframe in which the UE is allowed to transmit SPS-PUSCH is delayed by Koffset as compared to transmission per current specification.

Agreement:

For eMTC, on reception of a PDSCH ending in subframe n, the corresponding HARQ-ACK feedback on PUCCH is transmitted with a delay of Koffset as compared to transmission as per current specification.

Agreement:

For eMTC, the ending time for DL physical resources forming a CSI reference resource set is advanced by Koffset as compared to current specification.

Agreement:

For eMTC, for an MPDCCH received in subframe n that triggers aperiodic SRS transmission, SRS is transmitted with a delay of Koffset as compared to transmission as per current specification.

Agreement:

For eMTC, on receiving a timing advance command ending in subframe n, the corresponding adjustment of the uplink transmission timing by the received time advance shall be delayed by Koffset as compared to current specification.

Agreement:

For IoT NTN, support cell-specific Koffset configuration for use during initial access.

R1-2108519        FL summary 5 of AI 8.15.2 Timing relationship for IoT-NTN           Moderator (Sony)

From GTW session:

Agreement:

For IoT NTN, support the use of UE-specific Koffset in CONNECTED mode.

Agreement:

UE-specific TA reporting is supported in IoT-NTN

• FFS: Detailed contents of report

R1-2108637        FL summary 6 of AI 8.15.2 Timing relationship for IoT-NTN           Moderator (Sony)

Conclusion:

In IoT NTN the initialisation of generators for scrambling codes for UL channels and DM-RS shall use the subframe number of the UL channel or UL signal that is indicated by the Koffset-modified timing relationship.

NOTE: In the view of RAN1, this does not necessarily involve a specification change.

Conclusion:

For IoT NTN, no modifications are needed for the calculation in NR NTN for estimate of UE-eNB RTT.

8.15.33     Other

R1-2106776         On LEO satellite flyover timing and discontinuous coverage    Eutelsat S.A.

R1-2107175         Discussion on other aspects for NB-IoT/eMTC over NTN        Nokia, Nokia Shanghai Bell

R1-2107661         Mobile IoT in the 5G future – NB-IoT and eMTC for NTN      Ericsson

R1-2107676         Other aspects to support IoT in NTN              Huawei, HiSilicon

R1-2107781         Discussion on additional enhancement for IoT-NTN  ZTE

R1-2107911         Discussion on the other design aspects for IoT NTN   Xiaomi

 RAN1#106-bis-e

8.15   NB-IoT/eMTC support for Non-Terrestrial Network

Please refer to RP-211601 for detailed scope of the WI.

R1-2110622        Session notes for 8.15 (Study on NB-IoT/eMTC support for Non-Terrestrial Network)            Ad-Hoc Chair (Ericsson)

[106bis-e-R17-RRC-IoT-NTN] – Gilles (MediaTek)

Email discussion on Rel-17 RRC parameters for IoT over NTN

-        1^st check point: October 14

-        Final check point: October 19

R1-2110628        Summary of [106bis-e-R17-RRC-IoT-NTN]  IoT over NTN Moderator (MediaTek)

R1-2110629        List of IoT over NTN Rel-17 RRC parameters        Moderator (MediaTek)

Document is noted. For consolidation under 8 in [106bis-e-R17-RRC].

R1-2110672         3GPP TSG-RAN WG1 Agreements for Release-17  IoT NTN (post RAN1#106-bis-e)            WI rapporteur (MediaTek)

8.15.1     Enhancements to time and frequency synchronization

R1-2108750         Discussion on time and frequency synchronization enhancement for IoT in NTN               Huawei, HiSilicon

R1-2108931         Discussion on enhancements to time and frequency synchronization for IOT NTN               Spreadtrum Communications

R1-2109011         Discussion on time and frequency synchronization enhancements for NB-IoT/eMTC over NTN             vivo

R1-2109080         Discussion on enhancements to time and frequency synchronization      OPPO

R1-2109115         Enhancements to time and frequency synchronization Mavenir

R1-2109171         Enhancements to time and frequency synchronization for IoT NTN        MediaTek Inc.

R1-2109176         Enhancements to time and frequency synchronization Qualcomm Incorporated

R1-2109201         Time and frequency synchronization enhancement for IoT over NTN    CATT

R1-2109265         Enhancement to time and frequency synchronization for NB-IoT/eMTC over NTN               Nokia, Nokia Shanghai Bell

R1-2109308         Enhancements on time and frequency synchronization for IoT NTN       CMCC

R1-2109321         Time and frequency synchronization for IoT NTN      Lenovo, Motorola Mobility

R1-2109362         Enhancements to time and frequency synchronization NEC

R1-2109396         Discussion on time and frequency synchronization for IoT NTN             Xiaomi

R1-2109522         On enhancements to time and frequency synchronization         Samsung

R1-2109640         On synchronization for NB-IoT and eMTC NTN        Intel Corporation

R1-2109804         Enhancement to time synchronisation for IoT-NTN    Sony

R1-2109829         Enhancements to time and frequency synchronization to NB-IoT NTN  FGI, Asia Pacific Telecom, III, ITRI

R1-2109847         Discussion on synchronization for IoT-NTN ZTE

R1-2109956         On time and frequency synchronization enhancements for IoT NTN       Ericsson

R1-2110063         Discussion on Time and Frequency Synchronization in IoT NTN            Apple

R1-2110260         Enhancements to time and frequency synchronization Nordic Semiconductor ASA

[106bis-e-IoT-NTN-01] – Gilles (MediaTek)

Email discussion/approval on enhancements to time and frequency synchronization with checkpoints for agreements on October 14 and 19

R1-2109173        Summary #1 of AI 8.15.1  Enhancements to time and frequency synchronization for IoT NTN       Moderator (MediaTek Inc.)

R1-2110508        Summary #2 of AI 8.15.1  Enhancements to time and frequency synchronization for IoT NTN       Moderator (MediaTek Inc.)

From Oct 14^th GTW session

Proposal:

RAN1 has discussed the following aspects and leaves it up to RAN2 to specify UE behaviour related to expiry of UL synchronization validity timer and determine which of the following aspects are to be specified:

• Mechanisms for UE to declare RLF if UL synchronization validity timer becomes outdated in RRC_CONNECTED
• Mechanism for network to release connection, where UE may send UE release assistance indication signalling before UL synchronization validity timer becomes outdated in RRC_CONNECTED.
• ...

R1-2110536        Summary#3 of AI 8.15.1 Enhancements to time and frequency synchronization               Moderator (MediaTek)

From Oct 15^th GTW session

Agreement:

The validity timer for UL synchronization is started/restarted with configured timer validity duration at the epoch time of the assistance information (i.e. serving satellite ephemeris data).

·        FFS: Precise definition of epoch time taking into account SIB repetitions

Agreement:

A single validity duration for both serving satellite ephemeris and common TA related parameters is defined at least if serving satellite ephemeris and common TA parameters are signalled in the same SIB message.

Agreement:

Configuration of UL transmission segment is indicated on SIB at least for initial access

·        FFS via UE-specific RRC signalling in RRC_CONNECTED.

Agreement:

For eMTC PUSCH, a 3-bit field to indicate K=8 values for the uplink transmission segment duration:

·        Full-PRB allocation (unit: subframes): 2 4 8 16 32 64 128 256

·        Sub-PRB allocation (unit: resource units): 1 2 4 8 16 32 64 128

Agreement:

For eMTC, a 3-bit field is defined in the SIB to indicate the following K=8 values for the uplink transmission segment duration of PRACH:

·        (T_CP+T_SEQ+T_GP), 2*(T_CP+T_SEQ+T_GP), 4*(T_CP+T_SEQ+T_GP), 8*(T_CP+T_SEQ+T_GP), 16*(T_CP+T_SEQ+T_GP), 32*(T_CP+T_SEQ+T_GP), 64*(T_CP+T_SEQ+T_GP), 128*(T_CP+T_SEQ+T_GP) 

Agreement:

For eMTC, the same value is used for segment durations for all PRACH preambles

Agreement:

For NB-IOT, the same value is used for segment durations for all NPRACH preambles for a particular NPRACH format

Proposal:

RAN1 has discussed the following aspects and leaves it up to RAN2 to specify UE behaviour related to expiry of UL synchronization validity timer and determine which of the following aspects are to be specified:

• Mechanisms for UE to declare loss of UL synchronization (including mechanisms for ephemeris recovery, and UL synchronization loss reporting to the network) after loss of UL synchronization if UL synchronization validity timer or GNSS position fix become outdated in RRC_CONNECTED

·        Solutions discussed in RAN1 without reaching consensus are RLF, Release assistance indication signalling, and scheduling gap without releasing the RRC connection

• Mechanism for network to release connection, where UE may send UE release assistance indication signalling before UL synchronization validity timer or GNSS position fix become outdated in RRC_CONNECTED.

R1-2110550        Summary#4 of AI 8.15.1 Enhancements to time and frequency synchronization               Moderator (MediaTek)

From Oct 19^th GTW session

Agreement:

In eMTC/NB-IoT, N_TA update based on TA Command field in msg2 and MAC CE TA command is used for UL timing alignment correction as follows:

• No extension on TAC 11-bit field in Random Access Response
• When TAC (TA) in Msg2 is received, UE first adjustment and NTA is adjusted as follows: NTA,new = TA ´16, where TA is the timing advance command in msg2.
• When TACs ( provided within the MAC CE is received,  is updated as follows:
•  ,
• Where TA is the TAC field received in MAC CE command.

Agreement:

RAN1 has discussed the following aspects and leaves it up to RAN2 to specify UE behaviour related to expiry of UL synchronization validity timer and determine which of the following aspects are to be specified:

·        Mechanisms for UE to declare loss of UL synchronization including mechanisms for UL synchronization recovery procedure when UL synchronization is lost if UL synchronization validity timer expires in RRC_CONNECTED

o   It is up to RAN2 to specify this new behaviour for connected UE within RLF set of procedures or a new procedure for re-acquiring satellite ephemeris

o   Mechanism for UL synchronization includes re-acquiring the satellite ephemeris and common TA parameters if indicated on SIB

o   A new clause of RLF for loss of UL synchronization if validity timer for UL synchronization expires assuming a new re-interpretation of RLF set of procedures is specified for recovery of UL synchronization with re-acquisition of satellite ephemeris and common TA parameters if indicated

o   Potential additional RACH after re-acquisition of satellite ephemeris and common TA parameters if indicated for the UL synchronization recovery procedure in case of potential residual TA error.

·        If validity timer for UL synchronization expires and no UL synchronization recovery mechanisms specified as above, UE behaviour shall declare RLF and go into idle mode  autonomously to re-acquire ephemeris SIB. UE will then need to re-access the cell via Random Access procedure.

·        UE signalling to indicate the validity timer for UL synchronization is about to expire

R1-2110652        DRAFT LS on  Validity Timer for UL Synchronization for IoT NTN               Moderator (MediaTek)

Decision: As per email decision posted on Oct 22^nd, the draft LS is endorsed. Final version is approved in R1-2110673.

Final summary in R1-2110645.

8.15.2     Timing relationship enhancements

R1-2108751         Discussion on timing relationship enhancement for IoT in NTN              Huawei, HiSilicon

R1-2108932         Discussion on timing relationship enhancements for IOT NTN Spreadtrum Communications

R1-2109012         Discussion on timing relationship enhancements for NB-IoT/eMTC over NTN   vivo

R1-2109081         Discussion on timing relationship enhancements        OPPO

R1-2109116         Timing relationship enhancements  Mavenir

R1-2109172         Timing relationship enhancements for IoT NTN          MediaTek Inc.

R1-2109177         Timing relationship enhancements  Qualcomm Incorporated

R1-2109202         Timing relationship enhancement for IoT over NTN   CATT

R1-2109266         Timing relationship enhancements for NB-IoT/eMTC over NTN            Nokia, Nokia Shanghai Bell

R1-2109309         Discussion on timing relationship enhancements for IoT NTN CMCC

R1-2109322         Timing Relationship for IoT NTN   Lenovo, Motorola Mobility

R1-2109397         Discussion on the timing relationship enhancement for IoT NTN            Xiaomi

R1-2109523         Timing relationship enhancements  Samsung

R1-2109641         On timing relationship for NB-IoT and eMTC NTN   Intel Corporation

R1-2109805         Timing relationships enhancement for IoT- NTN        Sony

R1-2109830         Timing relationship enhancements to NB-IoT NTN    FGI, Asia Pacific Telecom, III, ITRI

R1-2109848         Discussion on timing relationship for IoT-NTN          ZTE

R1-2109957         On timing relationship enhancements for IoT NTN     Ericsson

R1-2110064         Discussion on Timing Relationship Enhancements in IoT NTN               Apple

R1-2110262         Timing relationship enhancements  Nordic Semiconductor ASA

[106bis-e-IoT-NTN-02] – Sam (Sony)

Email discussion/approval on timing relationship enhancements with checkpoints for agreements on October 14 and 19

R1-2110461        FL summary 1 of AI 8.15.2 Timing relationship for IoT-NTN           Moderator (Sony)

From Oct 12^th GTW session

Agreement:

In IoT NTN, for a random access procedure initiated by a N/MPDCCH order, the UE shall delay the transmission of the random access preamble by K_offset as compared to the current specification.

R1-2110462        FL summary 2 of AI 8.15.2 Timing relationship for IoT-NTN           Moderator (Sony)

From Oct 14^th GTW session

Agreement:

For eMTC in IoT NTN, if the UE determines that a preamble retransmission is necessary, the choice of a suitable preamble retransmission subframe shall be delayed by K_offset as compared to current specifications.

Agreement:

For NB-IoT, if the UE has initiated an NPUSCH transmission using pre-configured uplink resources ending in subframe n, the UE shall start or restart to monitor the NPDCCH from DL subframe n+4+K_mac (where K_mac is defined as in NR-NTN).

Agreement:

For eMTC, if the UE has initiated an PUSCH transmission using pre-configured uplink resources ending in subframe n, the UE shall start or restart to monitor the MPDCCH from DL subframe n+4+K_mac (where K_mac is defined as in NR-NTN).

Agreement:

Support PUR at least for GEO-based IoT NTN in Rel-17

FFS: for NGSO-based IoT NTN.

R1-2110533        FL summary 3 of AI 8.15.2 Timing relationship for IoT-NTN           Moderator (Sony)

From Oct 15^th GTW session

Agreement:

For IoT NTN, with respect to the granularity, configuration, indication and update of K_offset, the mechanisms concluded in NR-NTN shall be taken as baseline.

R1-2110534        FL summary 4 of AI 8.15.2 Timing relationship for IoT-NTN           Moderator (Sony)

From Oct 19^th GTW session

Agreement:

NPDCCH monitoring restrictions have been identified for further checking to see if changes for NB-IoT need to be made for the following cases:

·        case 1: MTBG NPUSCH

·        case 2: 2 NPUSCH HARQ processes scheduled

·        case 3: long single NPUSCH when MTBG or 2HARQ configured

·        case 4: single NPUSCH scheduled by DCI format N0 or RAR

·        case 5: NPUSCH format 2 in response to DCI format N1

·        case 6: NPRACH in response to PDCCH order

·        case 7: NPUSCH with same HARQ process when 2 HARQ configured

·        case 8: subframes after NPUSCH processing

·        case 9: subframes after NPUSCH carrying Msg3

·        case 10: NPRACH for SR for long NPRACH transmissions

·        case 11: NPRACH for SR for short NPRACH transmissions

·        FFS: the changes in each case

·        FFS: additional cases

8.15.33     Other

R1-2109267         Discussion on other aspects for NB-IoT/eMTC over NTN        Nokia, Nokia Shanghai Bell

R1-2109398         Discussion on the other design aspects for IoT NTN   Xiaomi

R1-2109750         Other aspects to support IoT in NTN              Huawei, HiSilicon

R1-2109849         Discussion on additional enhancement for IoT-NTN  ZTE

R1-2109958         Mobile IoT in the 5G future – NB-IoT and eMTC for NTN      Ericsson

 RAN1#107-e

8.15   NB-IoT/eMTC support for Non-Terrestrial Network

Please refer to RP-211601 for detailed scope of the WI.

R1-2112800        Session notes for 8.15 (Study on NB-IoT/eMTC support for Non-Terrestrial Network)            Ad-Hoc Chair (Huawei)

Rel-17 CRs related to LTE_NBIOT_eMTC_NTN

R1-2112420        Introduction of NB-IoT/eMTC support for Non-Terrestrial Networks in 36.213 s00-s05 Motorola Mobility

R1-2112421        Introduction of NB-IoT/eMTC support for Non-Terrestrial Networks in 36.213 s06-s07 Motorola Mobility

R1-2112422        Introduction of NB-IoT/eMTC support for Non-Terrestrial Networks in 36.213 s08-s09 Motorola Mobility

R1-2112423        Introduction of NB-IoT/eMTC support for Non-Terrestrial Networks in 36.213 s10-s13 Motorola Mobility

R1-2112424        Introduction of NB-IoT/eMTC support for Non-Terrestrial Networks in 36.213 s14-sxx Motorola Mobility

Decision: Draft CRs to 36.213 inc. agreements up to RAN1#106b-e. Endorsed, and to be revised to final CRs for RAN submission after RAN1#107-e.

R1-2112436        Introduction of NB-IoT/eMTC support in Non-Terrestrial Networks               Ericsson

Decision: Draft CR to 36.211 inc. agreements up to RAN1#106b-e. Endorsed, and to be revised to final CR for RAN submission after RAN1#107-e.

[107-e-R17-RRC-IoT-NTN] – Gilles (MediaTek)

Email discussion on Rel-17 RRC parameters for IoT over NTN

-        Email discussion to start on November 15

R1-2111376        Summary of [107-e-R17-RRC-IoT-NTN]  IoT over NTN     Moderator (MediaTek Inc.)

R1-2111377        List of IoT over NTN Rel-17 RRC parameters        Moderator (MediaTek Inc.)

Document is noted. For consolidation under 8 in [107-e-R17-RRC].

R1-2112891         3GPP TSG-RAN WG1 Agreements for Release-17 IoT NTN (post RAN1#107-e)               WI rapporteur (MediaTek)

8.15.1     Enhancements to time and frequency synchronization

R1-2110808         Discussion on time and frequency synchronization enhancement for IoT in NTN               Huawei, HiSilicon

R1-2111048         Remaining issues on time and frequency synchronization enhancements for NB-IoT/eMTC over NTN         vivo

R1-2111117         Discussion on enhancements to time and frequency synchronization for IOT NTN               Spreadtrum Communications

R1-2111172         Enhancements to time and frequency synchronization Mavenir

R1-2111182         Enhancements to time and frequency synchronization for IoT NTN        NEC

R1-2111236         Time and frequency synchronization enhancement for IoT over NTN    CATT

R1-2111276         Enhancement to time and frequency synchronization for NB-IoT/eMTC over NTN               Nokia, Nokia Shanghai Bell

R1-2111319         Discussion on enhancements to time and frequency synchronization      OPPO

R1-2111373         Enhancements to time and frequency synchronization for IoT NTN        MediaTek Inc.

R1-2111410         Remaining issues on time and frequency synchronisation for IoT-NTN Sony

R1-2112531         On time and frequency synchronization enhancements for IoT NTN       Ericsson (rev of R1-2111420)

R1-2111451         Enhancements to time and frequency synchronization Qualcomm Incorporated

R1-2111523         Remaining issues on synchronization for IoT NTN     Intel Corporation

R1-2111557         Discussion on time and frequency synchronization for IoT NTN             Xiaomi

R1-2111633         Enhancements on time and frequency synchronization for IoT NTN       CMCC

R1-2111662         Discussion on synchronization for IoT-NTN ZTE

R1-2111767         On enhancements to time and frequency synchronization         Samsung

R1-2111904         Time and Frequency Synchronization in IoT NTN      Apple

R1-2112002         Time and frequency synchronization for IoT NTN      Lenovo, Motorola Mobility

R1-2112329         Enhancements to time and frequency synchronization Nordic Semiconductor ASA

[107-e-IoT-NTN-01] – Gilles (MediaTek)

Email discussion/approval on enhancements to time and frequency synchronization with checkpoints for agreements on November 15 and 19

R1-2111375        Summary #1 of AI 8.15.1  Enhancements to time and frequency synchronization for IoT NTN       Moderator (MediaTek Inc.)

From Nov 12^th GTW session

Agreement

For UL Segmented transmission during RRC_CONNECTED:

·        If a segment duration is configured, the UE is expected to adjust the value for pre-compensation for a segment. 

·        FFS: UL transmission segment duration for NPDCCH ordered NPRACH/NPUSCH for NB-IoT and PDCCH ordered PRACH/PUSCH/PUCCH for eMTC is configurable by dedicated RRC Signalling

·        For UE pre-compensation per segment, further discuss how the following options apply from one segment to the next segment, and potential down-selection among the options:

o   Option 1: Skip / drop / insert samples

o   Option 2: puncture OFDM symbols

o   Option 3: Blanking subframes/slots where UE skip a slot or a subframe

o   FFS whether this can be left to UE implementation or if specification impact is needed

Decision: As per email decision posted on Nov 16^th,

Agreement

For eMTC PUCCH/PUSCH with frequency hopping enabled, the UE can adjust the uplink transmit timing when hopping to a new narrowband if the frequency hopping interval is less than or equal to the configured transmission segment duration.

Agreement

The following agreements from NR NTN are re-used for IoT NTN

·         The granularity of Common TA is set to be 1.Ts.

Conclusion

The following conclusion from NR NTN is re-used for IoT NTN

·         Conclusion: Do not define a TA margin.

R1-2112615        Summary #2 of AI 8.15.1  Enhancements to time and frequency synchronization for IoT NTN       Moderator (MediaTek Inc.)

From Nov 16^th GTW session

Agreement

For DL synchronization enhancements:

·        Signal Part-of ARFCN indication on MIB for bands where RAN4 cannot introduce a 200 kHz channel raster and the legacy 100 kHz raster is used, otherwise for bands where RAN4 can introduce a 200 kHz channel raster there is no signalling of the part-of ARFCN indication on MIB.

LS to RAN4

From post meeting

R1-2112689        DRAFT LS on  DL synchronization enhancements for IoT NTN      Moderator (MediaTek)

Decision: As per email decision posted on Dec 2^nd, the draft LS is endorsed. Final LS is approved in R1-2112768.

R1-2112679        Summary #3 of AI 8.15.1 Enhancements to time and frequency synchronization for IoT NTN       Moderator (MediaTek)

From Nov 18^th GTW session

For NPUSCH for NB-IoT and PUSCH/PUCCH for eMTC:

Agreement

UE pre-compensation per segment of NPUSCH for NB-IoT and PUSCH/PUCCH for eMTC is applied from one segment to the next segment by using one or more of the following methods if supported by UE implementation

·        UE may drop / Insert samples / Puncture OFDM symbols

·        UE may blank subframes / slots where UE skip a slot or a subframe

The total transmission time is not changed

UE autonomously Drop / insert samples / Puncture OFDM symbols or Blank subframes / slots where UE drops a subframe / slot

The method used for the UE pre-compensation is known to the eNB by a single UE capability

·        UE Blank subframes / slots where UE skip a slot or a subframe (slot is based on Sub Carrier Spacing)

FFS Details of method(s) to drop / insert samples, blanking subframes / slots (slot is based on Sub Carrier Spacing)

For NPRACH for NB-IoT and PRACH for eMTC:

Agreement

For NB-IoT, UE pre-compensation per segment of NPRACH is applied from one segment to the next segment by using one or more of the following methods if supported by UE implementation

·        UE may drop / Insert samples

·        UE may blank subframe / repetition unit where UE drops a subframe / repetition unit

The total transmission time is not changed

FFS Details of method(s) to drop / insert samples / blank subframe / repetition unit

FFS Specification impact

Agreement

For eMTC, UE pre-compensation per segment of PRACH is applied from one segment to the next segment by drop / insert samples in Guard Period of PRACH preamble.

·        The total transmission time is not changed

·        FFS Details of method(s) to drop / insert samples

UL segmented transmission configuration:

Agreement

UL transmission segment duration with one value X per NPUSCH for NB-IoT and PUSCH/PUCCH for eMTC may be indicated on SIB.

·        For NB-IoT/eMTC, X is one of K candidate values for the UL transmission segment duration of NPUSCH/PUSCH/PUCCH

·        The value X for eMTC PUSCH applies for full-PRB allocation and should be divided by 2, 4 and 8 for sub-PRB allocation of 6, 3 and 2-out-of-3 tones allocation, respectively.

Agreement

At least UL transmission segment duration with one value X for NPRACH for NB-IoT and PRACH for eMTC may be indicated on SIB

·        For NB-IoT/eMTC, X is one of K candidate values for the UL transmission segment duration of NPRACH/PRACH

·        FFS One value X, one or more values X_i

Agreement

UL Segmented transmission NPRACH/NPUSCH for NB-IoT is not supported in GEO based on UE feature.

Agreement

For NB-IoT NTN, the network configures one of K values for the UL transmission segment duration of each PRACH preamble format in a k-bit field, where the size of the k-bit field and the number of K candidate values depend on the preamble format.

·        Format 0 and format 1: 3-bit field, K=6 candidate values 2.4.(T_CP+T_SEQ), 4.4.(T_CP+T_SEQ), 8.4.(T_CP+T_SEQ), 16.4.(T_CP+T_SEQ), 32.4.(T_CP+T_SEQ), 64.4.(T_CP+T_SEQ)

·        Format 2: 3-bit field, K=5 candidate values 1.6.(T_CP+T_SEQ), 2.6.(T_CP+T_SEQ), 4.6.(T_CP+T_SEQ), 8.6.(T_CP+T_SEQ), 16.6.(T_CP+T_SEQ)

Agreement

Support network re-configuration of UL transmission segment by dedicated RRC Signalling.

Agreement

For IoT NTN, indicate two LSBs of the ARFCN in the MIB.

Decision: As per email decision posted on Nov 20^th,

GNSS validity:

Agreement

The UE autonomously determines its GNSS validity duration X and reports information associated with this valid duration to the network via RRC signalling.

·        X = {10s, 20s, 30s, 40s, 50s, 60s, 5 min, 10 min, 15 min, 20 min, 25 min, 30 min, 60 min, 90 min, 120 min, infinity}

Agreement

Send LS to RAN2 to take the following RAN1 agreements into consideration to specify the aspects related to GNSS position validity:

·        For sporadic short transmission, UE in RRC_CONNECTED should go back to idle mode and re-acquire a GNSS position fix if GNSS becomes outdated

·        The UE autonomously determines its GNSS validity duration X and reports information associated with this valid duration to the network via RRC signalling.

o   X = {10s, 20s, 30s, 40s, 50s, 60s, 5 min, 10 min, 15 min, 20 min, 25 min, 30 min, 60 min, 90 min, 120 min, infinity}

·        Note: The duration of the short transmission is no longer than the “validity timer for UL synchronization” referred to in the WID objective (but which still needs further discussion for specifying further details)

From post meeting

R1-2112847        DRAFT LS on  GNSS Validity duration for IoT NTN          Moderator (MediaTek)

Decision: As per email decision posted on Dec 1^st, the draft LS is endorsed. Final LS is approved in R1-2112848.

Long UL Transmission

Agreement

For eMTC PUCCH, a 3-bit field to indicate K=7 values for the uplink transmission segment duration:

·        2 4 8 16 32 64 128 subframes

Agreement

For eMTC PUCCH/PUSCH with frequency hopping enabled, the UE can adjust the uplink transmit timing and transmit frequency when hopping to a new narrowband if the frequency hopping interval is less than or equal to the configured transmission segment duration.

Validity timer for UL synchronization:

Agreement

The serving satellite ephemeris and common TA related parameters are signalled in the same SIB message and have the same epoch time.

Agreement

A single validity duration for both serving satellite ephemeris and common TA related parameters is broadcast on the SIB.

Agreement

Validity timer for UL synchronization should be started/restarted with configured timer validity duration at the epoch time of the assistance information.

Agreement

Validity timer duration is configured per cell and indicated to the UE in X bits with:

·        Value range {5, 10, 15, 20, 25, 30, 35, 40, 45, 50, 55, 60, 120, 180, 240}

·        Unit is second

·        FFS Additional values for GEO

Synchronization aspects common to IoT NTN and NR NTN

Working assumption:

Higher-layer parameters TACommon, TACommonDrift, TACommonDriftVariation are indicated with the following range, granularity and bits allocation:

Agreement

Confirm the working assumption made at RAN1#106-bis-e on serving satellite ephemeris bit allocations for LEO/MEO/GEO based non-terrestrial access network:

• Support serving satellite ephemeris format bit allocations for LEO/MEO/GEO based non-terrestrial access network:
• Position and velocity state vector ephemeris format is 17 bytes payload.
• The field size for position (m) is 78 bits
• Position range is driven by GEO : +/- 42 200 km
• The quantization step is 1.3m for position
• The field size for velocity (m/s) is 54 bits
• Velocity range is driven by LEO@600 km: +/- 8000 m/s
• The quantization step is 0.06 m/s for Velocity
• Orbital parameter ephemeris format 18 byte payload
• Semi-major axis α (m) is 33 bits
• Range: [6500, 43000]km
• Eccentricity e is 19 bits
• Range: ≤ 0.015
• Argument of periapsis ω (rad) is 24 bits
• Range: [0, 2π]
• Longitude of ascending node (Ω rad) is 21 bits
• Range: [0, 2π]
• Inclination i (rad) is 20 bits
• Range: [- π/2 , + π/2]
• Mean anomaly M (rad) at epoch time to is 24 bits
• Range: [0, 2π]

Agreement

Using indicated Higher-layer Common TA parameters, if configured, the UE can determine the one-way propagation time ( used for  calculation as follows:

where:

·         ,  and

·         TACommon, TACommonDrift and TACommonDriftVariation are Common TA parameter defined in RAN1 Meeting #106-bis-e

·         is the distance between the satellite and the uplink time synchronization reference point divided by the speed of light. DL and UL are frame aligned at the reference point with an offset given by .

·          is derived by the UE based on to pre-compensate the two-way transmission delay between the uplink time reference point and the satellite.

Final summary in R1-2112803.

8.15.2     Timing relationship enhancements

R1-2110809         Discussion on timing relationship enhancement for IoT in NTN              Huawei, HiSilicon

R1-2111049         Remaining issues on timing relationship enhancements for NB-IoT/eMTC over NTN               vivo

R1-2111118         Discussion on timing relationship enhancements for IOT NTN Spreadtrum Communications

R1-2111173         Timing relationship enhancements  Mavenir

R1-2111183         Timing relationship enhancements for IoT NTN          NEC

R1-2111237         Timing relationship enhancement for IoT over NTN   CATT

R1-2111277         Timing relationship enhancements for NB-IoT/eMTC over NTN            Nokia, Nokia Shanghai Bell

R1-2111320         Discussion on timing relationship enhancements        OPPO

R1-2111374         Timing relationship enhancements for IoT NTN          MediaTek Inc.

R1-2111411         Remaining issues on timing relationship enhancements for IoT-NTN     Sony

R1-2111421         On timing relationship enhancements for IoT NTN     Ericsson

R1-2111452         Timing relationship enhancements  Qualcomm Incorporated

R1-2111524         Remaining issues on timing relationships for IoT NTN              Intel Corporation

R1-2111558         Discussion on the timing relationship enhancement for IoT NTN            Xiaomi

R1-2111634         Discussion on timing relationship enhancements for IoT NTN CMCC

R1-2111663         Discussion on timing relationship for IoT-NTN          ZTE

R1-2111768         Timing relationship enhancements  Samsung

R1-2111905         Timing Relationship Enhancements in IoT NTN         Apple

R1-2112003         Timing Relationship for IoT NTN   Lenovo, Motorola Mobility

R1-2112331         Timing relationship enhancements  Nordic Semiconductor ASA

[107-e-IoT-NTN-02] – Sam (Sony)

Email discussion/approval on timing relationship enhancements with checkpoints for agreements on November 15 and 19

R1-2112552        FL summary 1 of AI 8.15.2 Timing relationship for IoT-NTN           Moderator (Sony)

From Nov 12^th GTW session

Agreement

For IoT NTN, signalling one value for cell-specific K_offset in system information is supported.

Agreement

For IoT NTN, the unit of K_offset is subframe based on a 15kHz subcarrier spacing (i.e. 1 ms).

·        Further discuss the case where UL is using 3.75 kHz SCS

Agreement

For IoT NTN, the UE specific K_offset is provided and updated by the network using MAC CE.

Agreement

For IoT NTN, the information of K_mac is carried in system information.

Agreement

For IoT NTN, the unit of K_mac is subframe based on a 15kHz subcarrier spacing (i.e. 1 ms).

·        Further discuss the case where UL is using 3.75 kHz SCS

Agreement

Modification of the designation of subframes with NPDCCH monitoring restrictions is needed for at least Cases 1 to 6.

R1-2112553        FL summary 2 of AI 8.15.2 Timing relationship for IoT-NTN           Moderator (Sony)

From Nov 16^th GTW session

Agreement

Whether/how the “indicated value” of K_offset is translated into number of slots for different numerologies (i.e., 15 kHz and 3.75 kHz) is left to the spec-editor.

·        This resolves the bullet from previous agreement: Further discuss the case where UL is using 3.75 kHz SCS

Agreement

For IoT NTN, adopt the NR NTN agreement without modification for FR1: (a) the value range (i.e. 1 ms), (b) the quantity signalled (e.g. a differential UE specific K_offset) for the UE specific K_offset.

Agreement

For IoT NTN, adopt the NR NTN agreement without modification for FR1 for the value range of Kmac.

R1-2112554        FL summary 3 of AI 8.15.2 Timing relationship for IoT-NTN           Moderator (Sony)

From Nov 18^th GTW session

Conclusion:

Leave it to spec editor to formulate in the specs the NPDCCH monitoring restrictions for Cases 1 to 6. 

Explanatory Note for editor

When the UE changes from receiving on the DL to transmitting on the UL (or vice versa), immediately before/after the DL/UL switch the UE is not required to monitor an NPDCCH candidate in some DL subframes. The designation of these subframes in the spec needs to take the “effect” of the TA into consideration. There may be multiple ways to capture this in the specifications for (at least) Cases 1 to 6. Two options (in principle) are described below, to guide the spec editor to capture this as best he/she sees it. Examples of where the changes may apply for cases 1 to 6 can be found as examples in appendix A in R1-2112554.

Option 1: The DL subframes during which the UE is not required to monitor an NPDCCH candidate are described in terms of downlink subframe timing. This would typically involve inserting a “-TA” term in their indexing.

Option 2: The DL subframes during which the UE is not required to monitor an NPDCCH candidate are described in terms of uplink subframe timing using the indexing of the UL subframes that coincide in time with the DL subframes in question.

Agreement

Network can configure UE-specific TA reporting either a TA or UE location for connected mode UE

·        In case a TA is configured, NR NTN solutions are a baseline for the following UE-specific TA handling issues, 

o   Signaling – quantity (full or delta), range, number of bits 

o   Granularity of report

o   Frequency of reporting

o   Means of reporting

o   NOTE: Any changes needed for IoT NTN can be made.

·        In case the UE location is configured, RAN2 will design solutions for the UE location information, and it is left to RAN2 to decide whether to support UE location reporting

8.15.33     Other

R1-2111278         Discussion on other aspects for NB-IoT/eMTC over NTN        Nokia, Nokia Shanghai Bell

R1-2111422         Mobile IoT in the 5G future – NB-IoT and eMTC for NTN      Ericsson

R1-2111559         Discussion on the other design aspects for IoT NTN   Xiaomi

R1-2111664         Discussion on additional enhancement for IoT-NTN  ZTE

R1-2111925         Other aspects to support IoT in NTN              Huawei, HiSilicon

 RAN1#107-bis-e

8.144   Maintenance on NB-IoT/eMTC support for Non-Terrestrial Network

Void (not be handled during this e-meeting).

 RAN1#108-e

8.14   Maintenance on NB-IoT/eMTC support for Non-Terrestrial Network

R1-2202792        Session notes for 8.14 (Maintenance on NB-IoT/eMTC support for Non-Terrestrial Network)       Ad-Hoc Chair (CMCC)

[108-e-R17-RRC-IoT-NTN] – Gilles (MediaTek)

Email discussion on Rel-17 RRC parameters for IoT over NTN

-        1^st check point for first LS in [108-e-R17-RRC]: February 24

-        Final check point for second LS in [108-e-R17-RRC] if necessary: March 3

R1-2201220        List of IoT over NTN Rel-17 RRC parameters        Moderator (MediaTek Inc.)

Document is noted. For consolidation under 8 in [108-e-R17-RRC].

R1-2202937         List of RAN1 agreements for Rel-17 IoT NTN (Post RAN1#108-e)       WI Rapporteur (MediaTek)

8.14.1     Enhancements to time and frequency synchronization

R1-2200941         Maintenance on time and frequency synchronization enhancement for IoT in NTN               Huawei, HiSilicon

R1-2201217         Enhancements to time and frequency synchronization for IoT NTN        MediaTek Inc.

R1-2201275         Discussion on enhancements to time and frequency synchronization      OPPO

R1-2201342         Remaining issues on time and frequency synchronization enhancement for IoT over NTN       CATT

R1-2201559         Discussion on enhancements to time and frequency synchronization for IOT NTN               Spreadtrum Communications

R1-2201587         Remaining issues of time and frequency synchronization for NB-IoT/eMTC over NTN       Nokia, Nokia Shanghai Bell

R1-2201652         Enhancements to time and frequency synchronization Qualcomm Incorporated

R1-2201789         Remaining Issues of Uplink Time and Frequency Synchronization for IoT NTN               Apple

R1-2201808         On time and frequency synchronization maintenance issues for IoT over NTN               Ericsson Hungary Ltd

R1-2201880         Remaining issues on enhancements to time and frequency synchronization for IoT NTN       CMCC

R1-2201950         Remaining issues on UL time and frequency synchronization for IoT NTN               Xiaomi

R1-2202210         Remaining issues of synchronization for NR-NTN     ZTE

R1-2202408         Maintenance of IoT-NTN time and frequency synchronisation Sony

R1-2202479         Enhancements to time and frequency synchronization Mavenir

[108-e-R17-IoT-NTN-01] – Gilles (MediaTek)

Email discussion for maintenance on enhancements to time and frequency synchronization

-        1^st check point: February 25

-        Final check point: March 3

R1-2201219        "Summary #1 of AI 8.14.1 Enhancements to time and frequency synchronization for IoT NTN"     Moderator (MediaTek Inc.)

From Feb 23^rd GTW session

Agreement

·        For IoT NTN, capture into 36.300 a stage-2 description of concept of K_offset, K-mac, UE pre-compensation of timing and frequency pre-compensation/adjustment for uplink transmission with modification as needed

NOTE: NR NTN agreements on TS 38.300 relating to a stage-2 description of concept of K_offset, K-mac, UE pre-compensation of timing and frequency pre-compensation/adjustment for uplink transmission can be adopted for TS 36.300 with modification as needed and can include aspects specific to IoT NTN as needed.

Decision: As per email decision posted on Feb 26^th,

Agreement

The TP below for TS 36.211 Section 8.1 is endorsed.

--------------------------------------- Start of TP for 3GPP TS 36.211 ----------------------------------------

8.1  Uplink-downlink frame timing

<Unchanged Text Omitted>

Transmission of the uplink radio frame number  from the UE shall start  seconds before the start of the corresponding downlink radio frame at the UE.

Figure 8.1-1: Uplink-downlink timing relation

<Unchanged Text Omitted>

---------------------------------------- End of TP for 3GPP TS 36.211 ----------------------------------------

Agreement

The TP below for TS 36.211 Section 8.1 is endorsed.

---------------------------------------- Start of TP for 3GPP TS 36.211 ----------------------------------------

8.1  Uplink-downlink frame timing

<Unchanged Text Omitted>

The quantity  is derived from the higher-layer parameters TACommon, TACommonDrift, and TACommonDriftVariation if configured (see Clause 4.2.3 in [TS 36.213]), otherwise .

<Unchanged Text Omitted>

---------------------------------------- End of TP for 3GPP TS 36.211 ----------------------------------------

Agreement

First discuss for additional values of validity timer for GEO in NR NTN AI 8.4.2. For IoT NTN, adopt the NR NTN agreement without modification for additional values of validity timer for GEO.

Conclusion

RAN1 can wait for RAN2 to conclude discussions on GNSS Measurements.

Conclusion

RAN1 can wait for RAN2 to conclude discussions on validity timer / re-acquisition on NTN-specific SIB.

Conclusion

RAN2 can further discuss when the UE-specific TA report is reported.

Agreement

Satellite velocity vector range can be discussed in NR NTN 8.4.2 first. IoT NTN can use conclusion / agreement from NR NTN without any modification.

Decision: As per email decision posted on Mar 1^st,

Agreement

The TP below for TS 36.211 Section 8.1 is endorsed.

---------------------------------------- Start of TP for 3GPP TS 36.211 ----------------------------------------

8.1  Uplink-downlink frame timing

<Unchanged Text Omitted>

The quantity  is computed by the UE based on UE position and serving satellite-ephemeris-related higher-layers parameters if configured, otherwise .

<Unchanged Text Omitted>

---------------------------------------- End of TP for 3GPP TS 36.211 ----------------------------------------

R1-2202724        Summary #2 of AI 8.14.1 Enhancements to time and frequency synchronization for IoT NTN       Moderator (MediaTek)

From Mar 1^st GTW session

Agreement

Modify bit allocations for orbital parameters ephemeris format as follows:

·        Orbital parameters are indicated in 21 bytes payload:

• Semi-major axis α (m) is 33 bits
• Range: from 6500 km to 43000 km
• The quantization step is 4.249 m
• Eccentricity e is 20 bits
• Range: ≤ 0.015
• The quantization step is 1.431
• Argument of periapsis ω (rad) is 28 bits
• Range: from 0 to 2π
• The quantization step is 2.341  rad
• Longitude of ascending node (Ω rad) is 28 bits
• Range: from 0 to 2π
• The quantization step is 2.341   rad
• Inclination i (rad) is 27 bits
• Range: from - π/2  to + π/2
• The quantization step is 2.341   rad
• Mean anomaly M (rad) at epoch time to is 28 bits
• Range: from 0 to 2π
• The quantization step is 2.341   rad

Agreement

For epoch time signaling for IoT NTN:

·        When explicitly provided through SIB, Epoch time of assistance information (i.e. Serving satellite ephemeris and Common TA parameters) is the starting time of a DL sub-frame, indicated by a SFN and a sub-frame number signaled together with the assistance information.

·        When provided through dedicated signaling, epoch time of assistance information (i.e. Serving satellite ephemeris and Common TA parameters) is the starting time of a DL sub-frame, indicated by a SFN and a sub-frame number.

·        The reference point for epoch time of the serving satellite ephemeris and Common TA parameters is the uplink time synchronization reference point.

R1-2202839         Summary #3 of AI 8.14.1 Enhancements to time and frequency synchronization for IoT NTN               Moderator (MediaTek)

Decision: As per email decision posted on Mar 3^rd,

Working assumption

Adopt NR NTN solution for negative TACommonDriftVariation values.

Working assumption

Adopt NR NTN solution for interpretation SFN indicating Epoch time.

R1-2202917        RAN1 IoT NTN additions for TS 36.300   Moderator (MediaTek)

Decision: As per email decision posted on Mar 7^th, the draftCR for TS36.300 is endorsed in R1-2202917, and shall be attached to the LS to RAN2.

R1-2202930        Draft LS on IoT-NTN TP for TS 36.300    Moderator (MediaTek)

Decision: As per email decision posted on Mar 7^th, the draft LS is endorsed. Final version is approved in R1-2202931.

Final summary in R1-2202915.

8.14.2     Timing relationship enhancements

R1-2200942         Maintenance on timing relationship enhancement for IoT in NTN           Huawei, HiSilicon

R1-2201218         Timing relationship enhancements for IoT NTN          MediaTek Inc.

R1-2201276         Discussion on timing relationship enhancements        OPPO

R1-2201343         Remaining issues on timing relationship enhancement for IoT over NTN               CATT

R1-2201586         Maintenance of IoT-NTN timing relationships            Sony

R1-2201588         Remaining issues of timing relationship enhancements for NB-IoT/eMTC over NTN               Nokia, Nokia Shanghai Bell

R1-2201653         Timing relationship enhancements  Qualcomm Incorporated

R1-2201790         Remaining Issues of Timing Relationship Enhancement for IoT NTN    Apple

R1-2201809         On timing relationship maintenance issues for IoT over NTN   Ericsson Hungary Ltd

R1-2201881         Remaining issues on timing relationship enhancements for IoT NTN     CMCC

R1-2202211         Remaining issues of timing relationship for IoT-NTN ZTE

R1-2202480         Timing relationship enhancements  Mavenir

[108-e-R17-IoT-NTN-02] – Sam (Sony)

Email discussion for maintenance on timing relationship enhancements

-        1^st check point: February 25

-        Final check point: March 3

R1-2202585        FL summary 1 of AI 8.14.2 Timing relationship for IoT-NTN           Moderator (Sony)

From Feb 23^rd GTW session

Agreement

RAN1 kindly suggests to spec editor of TS 36.213 to move the following text to the head of section 6.1.1:

========= Unchanged Text Omitted ==========

Throughout this clause, for a BL/CE UE, if the UE is configured with the higher layer parameter CellSpecificKoffset,

-               where

                is the parameter CellSpecificKoffset provided by higher layers, and

                is the parameter UESpecificKoffset provided by higher layers, otherwise

otherwise,

-              , .

======== Unchanged Text Omitted ===============

Agreement

The following TP for TS 36.213 section 9.1.5 is adopted:

<<<<< Start of TP to TS 36.213 section 9.1.5 >>>>>>>

If the UE has initiated a PUSCH transmission using preconfigured uplink resource ending in subframe n, the UE shall monitor the MPDCCH UE-specific search space in a search space window starting in subframe n+4+K_mac K_mac with duration given by higher layer parameter pur-MPDCCH-SS-window-duration where  is provided by higher layer parameter K-mac, otherwise . Upon detection of a MPDCCH with DCI format 6-0A/6-0B with CRC scrambled by PUR-RNTI intended for the UE within the search space window and the corresponding DCI is for PUR ACK/fallback indication (as defined in [4]), the UE is not required to monitor the MPDCCH UE-specific search space for the remaining search space window duration.

<<<<< End of TP to TS 36.213 section 9.1.5 >>>>>>>

Agreement

The following TP for TS 36.213 section 16.5.1 is adopted:

<<<< START of TEXT PROPOSAL for TS36.213 section 16.5.1 >>>>>>>>>>>>>

16.5.1  UE procedure for transmitting format 1 narrowband physical uplink shared channel

NPUSCH format 1 transmission can be scheduled by a NPDCCH with DCI format N0, or the transmission can correspond to using preconfigured uplink resource configured by higher layers. Transmission using preconfigured uplink resource is initiated by higher layers as specified in [14] , while retransmission of transport blocks transmitted using preconfigured uplink resource are scheduled by a NPDCCH with DCI format N0.

A UE shall upon detection on a given serving cell of a NPDCCH with DCI format N0 ending in NB-IoT DL subframe n scheduling NPUSCH intended for the UE, perform, at the end of

-     n+k₀+K_offset DL subframe for FDD,

-     k₀ NB-IoT UL subframes following the end of n+8+K_offset subframe for TDD,

a corresponding NPUSCH transmission using NPUSCH format 1 in N consecutive NB-IoT UL slots n_i with i = 0, 1, …, N-1 according to the NPDCCH information where

-     subframe n is the last subframe in which the NPDCCH is transmitted and is determined from the starting subframe of NPDCCH transmission and the DCI subframe repetition number field in the corresponding DCI; and

-     , where the value of is determined by the repetition number field in the corresponding DCI (see Clause 16.5.1.1), the value of is determined by the resource assignment field in the corresponding DCI (see Clause 16.5.1.1), the value of  is the number of NB-IoT UL slots of the resource unit (defined in clause 10.1.2.3 of [3]) corresponding to the  allocated number of subcarriers (as determined in Clause 16.5.1.1) in the corresponding DCI, and the value of is determined by the Number of scheduled TB for Unicast field, if present, in the corresponding DCI,  otherwise

-     n₀ is the first NB-IoT UL slot starting after the end of subframe n+k₀+K_offset for FDD

-     n₀ is the first NB-IoT UL slot starting after k₀ NB-IoT UL subframes following the end of n+8+K_offset subframe for TDD

-     value of k₀ is determined by the scheduling delay field () in the corresponding DCI according to Table 16.5.1-1 for FDD and Table 16.5.1-1A for TDD

<<<< END of TEXT PROPOSAL for TS36.213 section 16.5.1 >>>>>>>>>>>>>

Agreement

The following TP for TS 36.213 section 8.0 is adopted:

<<<< START of TEXT PROPOSAL for TS36.213 section 8.0 >>>>>>>>>>>>>

A BL/CE UE shall upon detection on a given serving cell of an MPDCCH with DCI format 6-0A/6-0B scheduling PUSCH intended for the UE, perform a corresponding PUSCH transmission in subframe(s) n_i = n+k_i+K_offset if a transport block(s) corresponding to the HARQ process(es) of the PUSCH transmission is generated as described in [8] with i = 0, 1, …, N_TBN-1 according to the MPDCCH, where

-     subframe n is the last subframe in which the MPDCCH is transmitted;

-     the value of is the number of scheduled TB determined by the corresponding DCI if present,  otherwise;

-      and the value of  is determined by the repetition number field in the corresponding DCI, where